Red Hat Training
A Red Hat training course is available for Red Hat Ceph Storage
トラブルシューティングガイド
Red Hat Ceph Storage のトラブルシューティング
概要
第1章 初期のトラブルシューティング
本章では、以下の情報を提供します。
- Ceph エラーのトラブルシューティングを開始する方法(「問題の特定」)
-
最も一般的な
ceph の正常性エラーメッセージ
(「ceph health
コマンドの出力について」) - 最も一般的な Ceph ログのエラーメッセージ(「Ceph ログについて」)
1.1. 問題の特定
発生した Red Hat Ceph Storage でエラーの原因を確認するには、以下の質問に回答します。
- サポート対象外の設定を使用する場合は、特定の問題が発生する可能性があります。設定がサポートされていることを確認してください。詳細は、Red Hat Ceph Storage でサポートされる設定について参照してください。
どの Ceph コンポーネントが問題を引き起こすかについて把握しているか?
- いいえ、「Ceph Storage クラスターの正常性の診断」 に従います。
- 監視。4章監視のトラブルシューティング を参照してください。
- OSD:5章OSD のトラブルシューティング を参照してください。
- 配置グループ7章配置グループのトラブルシューティング を参照してください。
1.1.1. Ceph Storage クラスターの正常性の診断
以下の手順では、Ceph Storage クラスターの正常性を診断するための基本的な手順を説明します。
クラスターの全体的なステータスを確認します。
# ceph health detail
コマンドが
HEALTH_WARN
またはHEALTH_ERR
を返す場合は、「ceph health
コマンドの出力について」 を参照してください。-
Ceph ログで 「Ceph ログについて」 に記載されたエラーメッセージがあるかどうかを確認します。ログは、デフォルトで
/var/log/ceph/
ディレクトリーにあります。 - ログに十分な量の情報が含まれていない場合は、デバッグレベルを増やし、失敗したアクションの再現を試行します。詳しくは、2章ロギングの設定 を参照してください。
-
ceph-medic
ユーティリティーを使用して、ストレージクラスターを診断します。詳細は、『Red HatCeph Storage 3 管理ガイド』の「Cephストレージクラスターの診断
」セクションを参照してください。
1.2. ceph health
コマンドの出力について
ceph health
コマンドは、Ceph Storage Cluster のステータスについての情報を返します。
-
HEALTH_OK
はクラスターが正常であることを示します。 -
HEALTH_WARN
は警告を示します。場合によっては、Ceph のステータスはHEALTH_OK に自動的に戻ります
。たとえば、Ceph がリバランスプロセスを終了する場合などです。ただし、クラスターがHEALTH_WARN
の状態であればさらにトラブルシューティングを行うことを検討してください。 -
HEALTH_ERR
は、早急な対応が必要なより深刻な問題を示します。
ceph health detail
および ceph -s
コマンドを使用して、より詳細な出力を取得します。
以下の表は、モニター、OSD、配置グループに関連する最も一般的な
エラーメッセージを示しています。この表は、エラーを説明し、問題を修正するための特定の手順を示す対応するセクションへのリンクを提供します。
HEALTH_ERR
および HEALTH_WARN
表1.1 モニターに関連するエラーメッセージ
エラーメッセージ | 参照 |
---|---|
| |
| |
| |
|
表1.2 Ceph Manager デーモンに関連するエラーメッセージ
エラーメッセージ | 参照 |
---|---|
| |
|
表1.3 OSD に関連するエラーメッセージ
エラーメッセージ | 参照 |
---|---|
| |
| |
| |
| |
| |
| |
|
表1.4 配置グループに関連するエラーメッセージ
エラーメッセージ | 参照 |
---|---|
| |
| |
| |
| |
| |
| |
|
1.3. Ceph ログについて
デフォルトでは、Ceph はログを /var/log/ceph/
ディレクトリーに保存します。
<cluster-name>.log
は、グローバルクラスターイベントを含むメインのクラスターログファイルです。デフォルトでは、このログの名前は ceph.log
です。Monitor ホストのみには、メインのクラスターログが含まれます。
各 OSD および Monitor には、<cluster-name>-osd.<number>.log および
という名前の独自のログファイルがあります。
<cluster-name
>-mon.<hostname>.log
Ceph サブシステムのデバッグレベルを増やすと、Ceph はこれらのサブシステムに新しいログファイルを生成します。ロギングの詳細は、2章ロギングの設定 を参照してください。
以下の表は、Monitor および OSD に関連する最も一般的な Ceph ログのエラーメッセージを示しています。この表は、エラーを説明し、それらを修正するための特定の手順を示す対応するセクションへのリンクを提供します。
表1.5 Ceph Logs の一般的なエラーメッセージ(Monitor に関連するメッセージ)
エラーメッセージ | ログファイル | 参照 |
---|---|---|
| 主なクラスターのログ | |
| 主なクラスターのログ | |
| 監視ログ | |
| 監視ログ | |
| 監視ログ |
表1.6 OSD に関連する Ceph Logs の一般的なエラーメッセージ
エラーメッセージ | ログファイル | 参照 |
---|---|---|
| 主なクラスターのログ | |
| 主なクラスターのログ | |
| 主なクラスターのログ | |
| OSD ログ | |
| OSD ログ |
第2章 ロギングの設定
本章では、さまざまな Ceph サブシステムのロギングを設定する方法について説明します。
ロギングはリソース集約型です。また、詳細ロギングは、比較的短い時間で大量のデータを生成できます。クラスターの特定のサブシステムで問題が発生しているので、そのサブシステムのロギングのみが有効になります。詳細は、「Ceph サブシステム」 を参照してください。
さらに、ログファイルのローテーションの設定を検討してください。詳しくは、「ログローテーションの加算」 を参照してください。
発生したら、サブシステムのログとメモリーレベルをデフォルト値に変更します。すべての Ceph サブシステムのリストおよびそのデフォルト値については、「 付録A サブシステムのデフォルトロギングレベルの値 」を参照してください。
以下を行って Ceph ロギングを設定することができます。
-
ランタイム時に
ceph
コマンドを使用します。これは最も一般的な方法です。詳しくは、「ランタイム時のロギング設定」 を参照してください。 - Ceph 設定ファイルの更新クラスターの起動時に問題が発生した場合は、このアプローチを使用します。詳しくは、「Ceph 設定ファイルにおけるロギング設定」 を参照してください。
2.1. Ceph サブシステム
本項では、Ceph サブシステムとそれらのロギングレベルについて説明します。
Ceph サブシステムおよびロギングレベルの理解
Ceph は複数のサブシステムで構成されます。各サブシステムには、以下のログレベルがあります。
-
デフォルトで
/var/log/ceph/
ディレクトリー (ログレベル) に保存されている出力ログ - メモリーキャッシュ(メモリーレベル)に保存されるログ
通常、Ceph は以下がない限り、メモリーに保存されているログを出力ログに送信しません。
- 致命的なシグナルが出されました。
- ソースコードの assert がトリガーされます。
- リクエストします
これらのサブシステムごとに異なる値を設定できます。Ceph のロギングレベルは、1
から 20
の範囲で動作します。1
は簡潔で、20
は詳細です。
ログレベルおよびメモリーレベルに単一の値を使用して、両方の値を同じ値に設定します。たとえば、debug_osd = 5
の場合には、ceph-osd
デーモンのデバッグレベルを 5
に設定します。
出力ログレベルとメモリーレベルで異なる値を使用するには、値をスラッシュ (/
) で区切ります。たとえば、debug_mon = 1/5
の場合は、ceph-mon
デーモンのデバッグログレベルを 1
に設定し、そのメモリーログレベルを 5
に設定します。
最も使用される Ceph サブシステムとデフォルト値
サブシステム | ログレベル | メモリーレベル | 詳細 |
---|---|---|---|
| 1 | 5 | 管理ソケット |
| 1 | 5 | 認証 |
| 0 | 5 |
クラスターに接続するために |
| 1 | 5 | FileStore OSD バックエンド |
| 1 | 5 | OSD ジャーナル |
| 1 | 5 | メタデータサーバー |
| 0 | 5 | Monitor クライアントは、ほとんどの Ceph デーモンとモニター間の通信を処理します。 |
| 1 | 5 | モニター |
| 0 | 5 | Ceph コンポーネント間のメッセージングシステム |
| 0 | 5 | OSD デーモン |
| 0 | 5 | Monitor が合意に使用するアルゴリズム。 |
| 0 | 5 | Ceph のコアコンポーネントである、信頼できる自動分散オブジェクトストア |
| 0 | 5 | Ceph ブロックデバイス |
| 1 | 5 | Ceph Object Gateway |
ログ出力の例
以下の例は、Monitor および OSD の詳細を増やすと、ログのメッセージタイプを示しています。
デバッグ設定の監視
debug_ms = 5 debug_mon = 20 debug_paxos = 20 debug_auth = 20
Monitor Debug 設定のログ出力の例
2016-02-12 12:37:04.278761 7f45a9afc700 10 mon.cephn2@0(leader).osd e322 e322: 2 osds: 2 up, 2 in 2016-02-12 12:37:04.278792 7f45a9afc700 10 mon.cephn2@0(leader).osd e322 min_last_epoch_clean 322 2016-02-12 12:37:04.278795 7f45a9afc700 10 mon.cephn2@0(leader).log v1010106 log 2016-02-12 12:37:04.278799 7f45a9afc700 10 mon.cephn2@0(leader).auth v2877 auth 2016-02-12 12:37:04.278811 7f45a9afc700 20 mon.cephn2@0(leader) e1 sync_trim_providers 2016-02-12 12:37:09.278914 7f45a9afc700 11 mon.cephn2@0(leader) e1 tick 2016-02-12 12:37:09.278949 7f45a9afc700 10 mon.cephn2@0(leader).pg v8126 v8126: 64 pgs: 64 active+clean; 60168 kB data, 172 MB used, 20285 MB / 20457 MB avail 2016-02-12 12:37:09.278975 7f45a9afc700 10 mon.cephn2@0(leader).paxosservice(pgmap 7511..8126) maybe_trim trim_to 7626 would only trim 115 < paxos_service_trim_min 250 2016-02-12 12:37:09.278982 7f45a9afc700 10 mon.cephn2@0(leader).osd e322 e322: 2 osds: 2 up, 2 in 2016-02-12 12:37:09.278989 7f45a9afc700 5 mon.cephn2@0(leader).paxos(paxos active c 1028850..1029466) is_readable = 1 - now=2016-02-12 12:37:09.278990 lease_expire=0.000000 has v0 lc 1029466 .... 2016-02-12 12:59:18.769963 7f45a92fb700 1 -- 192.168.0.112:6789/0 <== osd.1 192.168.0.114:6800/2801 5724 ==== pg_stats(0 pgs tid 3045 v 0) v1 ==== 124+0+0 (2380105412 0 0) 0x5d96300 con 0x4d5bf40 2016-02-12 12:59:18.770053 7f45a92fb700 1 -- 192.168.0.112:6789/0 --> 192.168.0.114:6800/2801 -- pg_stats_ack(0 pgs tid 3045) v1 -- ?+0 0x550ae00 con 0x4d5bf40 2016-02-12 12:59:32.916397 7f45a9afc700 0 mon.cephn2@0(leader).data_health(1) update_stats avail 53% total 1951 MB, used 780 MB, avail 1053 MB .... 2016-02-12 13:01:05.256263 7f45a92fb700 1 -- 192.168.0.112:6789/0 --> 192.168.0.113:6800/2410 -- mon_subscribe_ack(300s) v1 -- ?+0 0x4f283c0 con 0x4d5b440
OSD デバッグ設定
debug_ms = 5 debug_osd = 20 debug_filestore = 20 debug_journal = 20
OSD デバッグ設定のログ出力の例
2016-02-12 11:27:53.869151 7f5d55d84700 1 -- 192.168.17.3:0/2410 --> 192.168.17.4:6801/2801 -- osd_ping(ping e322 stamp 2016-02-12 11:27:53.869147) v2 -- ?+0 0x63baa00 con 0x578dee0 2016-02-12 11:27:53.869214 7f5d55d84700 1 -- 192.168.17.3:0/2410 --> 192.168.0.114:6801/2801 -- osd_ping(ping e322 stamp 2016-02-12 11:27:53.869147) v2 -- ?+0 0x638f200 con 0x578e040 2016-02-12 11:27:53.870215 7f5d6359f700 1 -- 192.168.17.3:0/2410 <== osd.1 192.168.0.114:6801/2801 109210 ==== osd_ping(ping_reply e322 stamp 2016-02-12 11:27:53.869147) v2 ==== 47+0+0 (261193640 0 0) 0x63c1a00 con 0x578e040 2016-02-12 11:27:53.870698 7f5d6359f700 1 -- 192.168.17.3:0/2410 <== osd.1 192.168.17.4:6801/2801 109210 ==== osd_ping(ping_reply e322 stamp 2016-02-12 11:27:53.869147) v2 ==== 47+0+0 (261193640 0 0) 0x6313200 con 0x578dee0 .... 2016-02-12 11:28:10.432313 7f5d6e71f700 5 osd.0 322 tick 2016-02-12 11:28:10.432375 7f5d6e71f700 20 osd.0 322 scrub_random_backoff lost coin flip, randomly backing off 2016-02-12 11:28:10.432381 7f5d6e71f700 10 osd.0 322 do_waiters -- start 2016-02-12 11:28:10.432383 7f5d6e71f700 10 osd.0 322 do_waiters -- finish
関連項目
2.2. ランタイム時のロギング設定
ランタイム時に Ceph デバッグ出力である dout()
をアクティベートするには、以下を実行します。
ceph tell <type>.<id> injectargs --debug-<subsystem> <value> [--<name> <value>]
以下を置き換えます。
-
<type>
を Ceph デーモンのタイプ(osd、mon
)に置き換えます。、または
mds
-
<id>
: Ceph デーモンの特定の ID に置き換えてください。特定タイプのすべてのデーモンにランタイム設定を適用するには、*
を使用します。 -
<subsystem>
と特定のサブシステム詳しくは、「Ceph サブシステム」 を参照してください。 -
<value>
:1
から20
までの数字を入力します。ここで1
は簡潔で、20が冗長になります
。
たとえば、osd.0
という名前の OSD サブシステムのログレベルを 0 に設定し、メモリーレベルを 5 に設定するには、以下を実行します。
# ceph tell osd.0 injectargs --debug-osd 0/5
ランタイム時の設定を表示するには、以下を実行します。
-
実行中の Ceph デーモン (例:
ceph-osd
またはceph-mon
) でホストにログインします。 設定を表示します。
ceph daemon <name> config show | less
Ceph デーモンの名前を指定します。以下に例を示します。
# ceph daemon osd.0 config show | less
関連項目
- 「Ceph 設定ファイルにおけるロギング設定」
- 『Configuration Guide for Red Hat Ceph Storage 3』の「Logging ConfigurationReference 」の章
2.3. Ceph 設定ファイルにおけるロギング設定
起動時に Ceph のデバッグ出力を有効にするには、システムの起動時に dout()
のデバッグ設定を Ceph 設定ファイルに追加します。
-
各デーモンに共通するサブシステムの場合は、
[global]
セクションに設定を追加します。 -
特定のデーモンのサブシステムについては、
[mon]
、[osd]
、[mds]
などのデーモンセクションに設定を追加します。
以下に例を示します。
[global] debug_ms = 1/5 [mon] debug_mon = 20 debug_paxos = 1/5 debug_auth = 2 [osd] debug_osd = 1/5 debug_filestore = 1/5 debug_journal = 1 debug_monc = 5/20 [mds] debug_mds = 1
関連項目
- 「Ceph サブシステム」
- 「ランタイム時のロギング設定」
- 『Configuration Guide for Red Hat Ceph Storage 3』の「Logging ConfigurationReference 」の章
2.4. ログローテーションの加算
Ceph コンポーネントのデバッグレベルを増やすと、大量のデータを生成する可能性があります。ディスクがほぼ満杯になると、/etc/logrotate.d/ceph
にある Ceph ログローテーションファイルを変更することで、ログローテーションを迅速化することができます。Cron ジョブスケジューラーはこのファイルを使用してログローテーションをスケジュールします。
手順: ログローテーションの加算
ローテーション頻度後にサイズ設定をログローテーションファイルに追加します。
rotate 7 weekly size <size> compress sharedscripts
たとえば、500 MB に達するとログファイルをローテーションするには、以下のコマンドを実行します。
rotate 7 weekly size 500 MB compress sharedscripts size 500M
crontab
エディターを開きます。$ crontab -e
エントリーを追加して、
/etc/logrotate.d/ceph
ファイルを確認します。たとえば、Cron に 30 分ごとに/etc/logrotate.d/ceph
をチェックするように指示するには、以下を実行します。30 * * * * /usr/sbin/logrotate /etc/logrotate.d/ceph >/dev/null 2>&1
関連項目
- Red Hat Enterprise Linux 7 の『システム管理者のガイド』の「Cron を使用した繰り返しジョブのスケジュール設定」セクションを参照してください。
第3章 ネットワークの問題のトラブルシューティング
本章では、ネットワークおよび Network Time Protocol(NTP)に接続しているトラブルシューティング手順を説明します。
3.1. 基本的なネットワークのトラブルシューティング
Red Hat Ceph Storage は、信頼性の高いネットワーク接続によって大きく依存します。Red Hat Ceph Storage ノードは、ネットワークを使用して相互に通信します。ネットワークの問題が発生すると、Ceph OSD のフラッピングなどの多くの問題が発生するか、またはダウンとして誤って報告される可能性があります
。また、ネットワークの問題により Ceph Monitor のクロックの誤差エラーが引き起こされる可能性があります。さらに、パケットロス、レイテンシーが高い、または制限された帯域幅が、クラスターのパフォーマンスと安定性に影響を与える可能性があります。
手順: 基本的なネットワーキングのトラブルシューティング
net-tools
パッケージをインストールすると、Ceph Storage クラスターで発生する可能性のあるネットワーク問題のトラブルシューティングに役立ちます。例
[root@mon ~]# yum install net-tools [root@mon ~]# yum install telnet
Ceph 設定ファイルの
cluster_network
およびpublic_network
パラメーターに正しい値が含まれていることを確認します。例
[root@mon ~]# cat /etc/ceph/ceph.conf | grep net cluster_network = 192.168.1.0/24 public_network = 192.168.0.0/24
ネットワークインターフェースが起動していることを確認します。
例
[root@mon ~]# ip link list 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: enp22s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 40:f2:e9:b8:a0:48 brd ff:ff:ff:ff:ff:ff
Ceph ノードは、短縮ホスト名を使用して相互に通信できることを確認します。ストレージクラスターの各ノードでこれを確認します。
構文
ping SHORT_HOST_NAME
例
[root@mon ~]# ping osd01
ファイアウォールを使用する場合、Ceph ノードが適切なポートで他のノードにアクセスできることを確認します。
firewall-cmd
ツールとtelnet
ツールは、ポートのステータスを検証して、ポートが開いているかどうかを確認できます。構文
firewall-cmd --info-zone=ZONE telnet IP_ADDRESS PORT
例
[root@mon ~]# firewall-cmd --info-zone=public public (active) target: default icmp-block-inversion: no interfaces: enp1s0 sources: 192.168.0.0/24 services: ceph ceph-mon cockpit dhcpv6-client ssh ports: 9100/tcp 8443/tcp 9283/tcp 3000/tcp 9092/tcp 9093/tcp 9094/tcp 9094/udp protocols: masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: [root@mon ~]# telnet 192.168.0.22 9100
インターフェースカウンターにエラーがないことを確認します。ノード間のネットワーク接続がレイテンシーが予想され、パケットロスがないことを確認します。
ethtool
コマンドの使用:構文
ethtool -S INTERFACE
例
[root@mon ~]# ethtool -S enp22s0f0 | grep errors NIC statistics: rx_fcs_errors: 0 rx_align_errors: 0 rx_frame_too_long_errors: 0 rx_in_length_errors: 0 rx_out_length_errors: 0 tx_mac_errors: 0 tx_carrier_sense_errors: 0 tx_errors: 0 rx_errors: 0
ifconfig
コマンドの使用:例
[root@mon ~]# ifconfig enp22s0f0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 10.8.222.13 netmask 255.255.254.0 broadcast 10.8.223.255 inet6 2620:52:0:8de:42f2:e9ff:feb8:a048 prefixlen 64 scopeid 0x0<global> inet6 fe80::42f2:e9ff:feb8:a048 prefixlen 64 scopeid 0x20<link> ether 40:f2:e9:b8:a0:48 txqueuelen 1000 (Ethernet) RX packets 4219130 bytes 2704255777 (2.5 GiB) RX errors 0 dropped 0 overruns 0 frame 0 1 TX packets 1418329 bytes 738664259 (704.4 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 2 device interrupt 16
netstat
コマンドの使用:例
[root@mon ~]# netstat -ai Kernel Interface table Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg docker0 1500 0 0 0 0 0 0 0 0 BMU eno2 1500 0 0 0 0 0 0 0 0 BMU eno3 1500 0 0 0 0 0 0 0 0 BMU eno4 1500 0 0 0 0 0 0 0 0 BMU enp0s20u13u5 1500 253277 0 0 0 0 0 0 0 BMRU enp22s0f0 9000 234160 0 0 0 432326 0 0 0 BMRU 1 lo 65536 10366 0 0 0 10366 0 0 0 LRU
パフォーマンスの問題は、レイテンシーの確認や、ストレージクラスターのすべてのノード間のネットワーク帯域幅を検証するため、iperf3
ツールを使用します。iperf3
ツールは、サーバーとクライアント間のシンプルなポイントツーポイントネットワーク帯域幅テストを実行します。帯域幅を確認する Red Hat Ceph Storage ノードに
iperf3
パッケージをインストールします。例
[root@mon ~]# yum install iperf3
Red Hat Ceph Storage
ノードで、iperf3
サーバーを起動します。例
[root@mon ~]# iperf3 -s ----------------------------------------------------------- Server listening on 5201 -----------------------------------------------------------
注記デフォルトのポートは 5201
ですが、-P コマンド引数を使用して設定できます
。別の Red Hat Ceph Storage
ノードで、iperf3
クライアントを起動します。例
[root@osd ~]# iperf3 -c mon Connecting to host mon, port 5201 [ 4] local xx.x.xxx.xx port 52270 connected to xx.x.xxx.xx port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 114 MBytes 954 Mbits/sec 0 409 KBytes [ 4] 1.00-2.00 sec 113 MBytes 945 Mbits/sec 0 409 KBytes [ 4] 2.00-3.00 sec 112 MBytes 943 Mbits/sec 0 454 KBytes [ 4] 3.00-4.00 sec 112 MBytes 941 Mbits/sec 0 471 KBytes [ 4] 4.00-5.00 sec 112 MBytes 940 Mbits/sec 0 471 KBytes [ 4] 5.00-6.00 sec 113 MBytes 945 Mbits/sec 0 471 KBytes [ 4] 6.00-7.00 sec 112 MBytes 937 Mbits/sec 0 488 KBytes [ 4] 7.00-8.00 sec 113 MBytes 947 Mbits/sec 0 520 KBytes [ 4] 8.00-9.00 sec 112 MBytes 939 Mbits/sec 0 520 KBytes [ 4] 9.00-10.00 sec 112 MBytes 939 Mbits/sec 0 520 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 1.10 GBytes 943 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 1.10 GBytes 941 Mbits/sec receiver iperf Done.
この出力には、Red Hat Ceph Storage ノード間の 1.1 Gbits/秒
のネットワーク帯域幅と、テスト中の再送信なしが表示されます
。Red Hat は、ストレージクラスター内のすべてのノード間のネットワーク帯域幅を検証することを推奨します。
全ノードに同じネットワーク相互接続速度があることを確認します。割り当てられているノードの速度が遅くなると、接続速度が遅くなる可能性があります。また、相互スイッチリンクがアタッチされたノードの集約された帯域幅を処理できることを確認します。
構文
ethtool INTERFACE
例
[root@mon ~]# ethtool enp22s0f0 Settings for enp22s0f0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised pause frame use: Symmetric Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Link partner advertised pause frame use: Symmetric Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: 1000Mb/s 1 Duplex: Full 2 Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on MDI-X: off Supports Wake-on: g Wake-on: d Current message level: 0x000000ff (255) drv probe link timer ifdown ifup rx_err tx_err Link detected: yes 3
関連項目
- Red Hat Enterprise Linux 7 のネットワークガイド
- 『Red Hat Ceph Storage 設定ガイド』の「MTU 値の検証および設定 」セクションを参照してください。
- カスタマーポータルのネットワーク問題のトラブルシューティングに関するナレッジベース記事およびソリューション
3.2. 基本的な NTP のトラブルシューティング
本セクションでは、基本的な NTP トラブルシューティング手順を説明します。
手順: 基本的な NTP トラブルシューティング
ntpd
デーモンが Monitor ホストで実行されていることを確認します。# systemctl status ntpd
ntpd
が実行していない場合は、有効にして起動します。# systemctl enable ntpd # systemctl start ntpd
ntpd
がクロックを正しく同期していることを確認します。$ ntpq -p
- 詳細な NTP トラブルシューティングの手順は、Red Hat カスタマーポータルの NTP の問題のトラブルシューティングソリューションを参照してください。
関連項目
第4章 監視のトラブルシューティング
本章では、Ceph Monitor に関連する最も一般的なエラーを修正する方法を説明します。
作業を開始する前に
- ネットワーク接続を確認します。詳しくは、3章ネットワークの問題のトラブルシューティング を参照してください。
4.1. 監視に関連するほとんどの一般的なエラーメッセージ
以下の表には、ceph health detail
コマンドで返される、または Ceph ログに含まれる最も一般的なエラーメッセージを一覧表示しています。この表は、エラーを説明し、問題を修正するための特定の手順を示す対応するセクションへのリンクを提供します。
表4.1 モニターに関連するエラーメッセージ
エラーメッセージ | 参照 |
---|---|
| |
| |
| |
|
表4.2 Ceph Logs の一般的なエラーメッセージ(Monitor に関連するメッセージ)
エラーメッセージ | ログファイル | 参照 |
---|---|---|
| 主なクラスターのログ | |
| 主なクラスターのログ | |
| 監視ログ | |
| 監視ログ | |
| 監視ログ |
4.1.1. モニターがクォーラム外である
1 つ以上の Monitor は down
とマークされますが、他の Monitor はクォーラムを形成できます。さらに、ceph health detail
コマンドは、以下のようなエラーメッセージを返します。
HEALTH_WARN 1 mons down, quorum 1,2 mon.b,mon.c mon.a (rank 0) addr 127.0.0.1:6789/0 is down (out of quorum)
エラー内容:
Ceph は、さまざまな理由で Monitor を down
とマークします。
ceph-mon
デーモンが実行していない場合は、ストアが破損しているか、その他のエラーによりデーモンを起動できません。また、/var/
パーティションが満杯になっている可能性もあります。そのため、ceph-mon
は、デフォルトで /var/lib/ceph/mon-<short-host-name>/store.db
にあるストアに対する操作を実行することができません。
ceph-mon
デーモンが実行中であるものの、Monitor がクォーラムから外れて down
とマークされた場合、問題の原因は Monitor の状態によって異なります。
-
Monitor がプローブの状態が予想よりも長くなっている場合は、他のモニターを見つけることができません。この問題は、ネットワークの問題によって引き起こされる可能性があります。モニターには古いモニターマップ
(monmap
)があり、誤った IP アドレスで他の Monitor に到達しようと試みます。または、monmap
が最新の状態の場合には、Monitor のクロックが同期されない場合があります。 - Monitor が期待値よりも長くなっている場合は、モニターのクロックが同期されない場合があります。
- Monitor が状態を同期して同期し、 戻す場合、クラスターの状態は構成になります。つまり、同期プロセスが処理できるよりも新しいマップが生成されることを意味します。
- Monitor がそれ自体をリーダーまたはペン としてマークした場合は、クォーラムにあると考えられますが、残りのクラスターはこれが検証されていないと思われます。この問題は、クロック同期の失敗によって引き起こされる可能性があります。
この問題を解決するには、以下を行います。
ceph-mon
デーモンが実行していることを確認します。そうでない場合は、起動します。systemctl status ceph-mon@<host-name> systemctl start ceph-mon@<host-name>
<host-name>
を、デーモンが実行されているホストの短い名前に置き換えます。不明な場合はhostname -s
コマンドを使用します。-
ceph-mon
」の手順に従います。を起動できない場合は、「ceph-mon
Daemon Cannot Start -
ceph-mon
デーモンを起動でき、ダウンとマークされている場合は
.、「ceph-mon Daemon Is Running」の手順に従ってくださいが、Still Marked as
down
ceph-mon
デーモンを起動できない
-
デフォルトでは、/var/log/ceph/ceph-mon.<host-name>.log
にある対応する Monitor ログを確認してください。 ログに以下のようなエラーメッセージが含まれる場合は、Monitor のストアが破損する可能性があります。
Corruption: error in middle of record Corruption: 1 missing files; e.g.: /var/lib/ceph/mon/mon.0/store.db/1234567.ldb
この問題を修正するには、Monitor を置き換えます。「失敗したモニターの置き換え」 を参照してください。
ログに以下のようなエラーメッセージが含まれる場合は、
/var/
パーティションが満杯になっている可能性があります。/var/
から不要なデータを削除します。Caught signal (Bus error)
重要Monitor ディレクトリーからデータを手動で削除しないでください。代わりに、
ceph-monstore-tool
を使用して圧縮します。詳しくは、「モニターストアの圧縮」 を参照してください。- 他のエラーメッセージが表示された場合は、サポートチケットを開きます。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。
ceph-mon
デーモンが実行しているが、down
としてマークされている
クォーラムの外にある Monitor
ホストから、mon_status
コマンドを使用してその状態を確認します。ceph daemon <id> mon_status
<id>
を Monitor の ID に置き換えます。以下に例を示します。# ceph daemon mon.a mon_status
ステータスが probing
の場合は、mon_status
の出力にある他の Monitor の場所を確認します。-
アドレスが正しくない場合、Monitor には間違った Monitor マップ
(monmap
)があります。この問題を修正するには、「モニターマップの挿入」 を参照してください。 - アドレスが正しい場合は、Monitor クロックが同期されていることを確認します。詳しくは、「クロックスキュー」 を参照してください。また、ネットワークに関する問題のトラブルシューティングを行う方法は 3章ネットワークの問題のトラブルシューティング を参照してください。
-
アドレスが正しくない場合、Monitor には間違った Monitor マップ
- ステータスが iselecting の場合には、Monitor クロックが同期されていることを確認します。「クロックスキュー」 を参照してください。
- 状態が 選択中 から 同期中 に変わる場合は、サポートチケットを作成してください。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。
- Monitor がリーダーまたはペン の場合は、Monitor クロックが同期されていることを確認します。「クロックスキュー」 を参照してください。クロックが同期されても問題が解決しない場合は、サポートチケットを開きます。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。
関連項目
- 「モニターの状態について」
- Red Hat Ceph Storage 3 の『Administration Guide』の 「Starting, Stop, Stoping a Daemon by Instances 」セクションを参照してください。
- Red Hat Ceph Storage 3 の『管理ガイド』の「管理 ソケットの使用 」セクション
4.1.2. クロックスキュー
Ceph Monitor がクォーラムを超えており、ceph health detail
コマンドの出力は、次のようなエラーメッセージが含まれています。
mon.a (rank 0) addr 127.0.0.1:6789/0 is down (out of quorum) mon.a addr 127.0.0.1:6789/0 clock skew 0.08235s > max 0.05s (latency 0.0045s)
また、Ceph ログには以下のようなエラーメッセージが含まれます。
2015-06-04 07:28:32.035795 7f806062e700 0 log [WRN] : mon.a 127.0.0.1:6789/0 clock skew 0.14s > max 0.05s 2015-06-04 04:31:25.773235 7f4997663700 0 log [WRN] : message from mon.1 was stamped 0.186257s in the future, clocks not synchronized
エラー内容:
クロックのスキューのエラーメッセージは
、モニターのクロックが同期されないことを示しています。Monitor は時間の精度に依存し、クロックが同期されていない場合に予測できない動作をするため、クロックの同期が重要になります。
mon_clock_drift_allowed
パラメーターは、クロック間のどのような不一致を許容するかを決定します。デフォルトでは、このパラメーターは 0.05 秒に設定されています。
以前のテストを行わずに mon_clock_drift_allowed
のデフォルト値を変更しないでください。この値を変更すると、通常は Monitor および Ceph Storage クラスターの安定性に影響する可能性があります。
clock skew
エラーの原因として、ネットワークの問題や Network Time Protocol (NTP) 同期の問題などがあります (設定されている場合)。また、仮想マシンにデプロイされた Monitor では時間同期が適切に動作しません。
この問題を解決するには、以下を行います。
- ネットワークが正しく機能することを確認します。詳細は 3章ネットワークの問題のトラブルシューティング を参照してください。NTP を使用している場合は、特に NTP クライアントに関する問題をトラブルシューティングします。詳細は、「基本的な NTP のトラブルシューティング」 を参照してください。
- リモートの NTP サーバーを使用する場合は、ネットワーク上に独自の NTP サーバーをデプロイすることを検討してください。詳細は、Red Hat Enterprise Linux 7 の『システム管理者のガイド』の「 ntpd を使用した NTP の設定 」の章を参照してください。
- NTP クライアントを使用しない場合は、up を 1 つ設定します。詳細は、Red Hat Ceph Storage 3インストールガイド(Red Hat Enterprise Linux またはUbuntu )の 「Configuring the Network Time Protocol forRed Hat Ceph Storage」セクションを参照してください。
- Monitor をホストするために仮想マシンを使用する場合は、ベアメタルホストに移動します。Monitors のホストでの仮想マシンの使用はサポートされていません。詳細は、Red Hat カスタマーポータルの「Red Hat Ceph Storage でサポートされる構成 」を参照してください。
Ceph は 5 分ごとに時刻同期を評価するため、問題を修正してから clock skew
メッセージを消去するまでに遅延が生じます。
関連項目
4.1.3. Monitor ストアは Getting Too Big です。
ceph health
コマンドは、以下のようなエラーメッセージを返します。
mon.ceph1 store is getting too big! 48031 MB >= 15360 MB -- 62% avail
エラー内容:
Ceph Monitors ストアは、エントリーをキーと値のペアとして保存する LevelDB データベースです。データベースにはクラスターマップが含まれ、デフォルトで /var/lib/ceph/mon/<cluster-name>-<short-host-name>/store.db
にあります。
大規模な Monitor ストアのクエリーには時間がかかる場合があります。その結果、Monitor はクライアントクエリーに応答して遅延する可能性があります。
さらに、/var/
パーティションが満杯になると、Monitor はストアへの書き込み操作を実行し、終了することはできません。この問題のトラブルシューティングに関する詳しい情報は、「モニターがクォーラム外である」 を参照してください。
この問題を解決するには、以下を行います。
データベースのサイズを確認します。
du -sch /var/lib/ceph/mon/<cluster-name>-<short-host-name>/store.db
クラスターの名前と、ceph-mon
が実行されているホストの短縮ホスト名を指定します。以下に例を示します。# du -sch /var/lib/ceph/mon/ceph-host1/store.db 47G /var/lib/ceph/mon/ceph-ceph1/store.db/ 47G total
- Monitor ストアを圧縮します。詳細は 「モニターストアの圧縮」 を参照してください。
関連項目
4.1.4. モニターの状態について
mon_status
コマンドは、以下のような Monitor についての情報を返します。
- 状態
- ランク
- 選出のエポック
-
監視マップ (
monmap
)
Monitor がクォーラムを形成する場合は、ceph
コマンドラインユーティリティーで mon_status
を使用します。
Monitor がクォーラムを形成できず、ceph-mon
デーモンが実行されている場合には、管理ソケットを使用して mon_status
を実行します。詳細は、Red Hat Ceph Storage 3 の『管理ガイド』の「管理 ソケットの使用 」セクションを参照してください。
mon_status
の出力例
{ "name": "mon.3", "rank": 2, "state": "peon", "election_epoch": 96, "quorum": [ 1, 2 ], "outside_quorum": [], "extra_probe_peers": [], "sync_provider": [], "monmap": { "epoch": 1, "fsid": "d5552d32-9d1d-436c-8db1-ab5fc2c63cd0", "modified": "0.000000", "created": "0.000000", "mons": [ { "rank": 0, "name": "mon.1", "addr": "172.25.1.10:6789\/0" }, { "rank": 1, "name": "mon.2", "addr": "172.25.1.12:6789\/0" }, { "rank": 2, "name": "mon.3", "addr": "172.25.1.13:6789\/0" } ] } }
状態の監視
- リーダー
-
選択フェーズ中に、Monitor はリーダーを選択します。リーダーは、ランクが最も高い Monitor で、ランクが最小値になります。上記の例では、リーダーは
mon.1
です。 - peon
- Peons は、リーダーではないクォーラムの Monitor です。リーダーが失敗すると、より多くのランクを持つ繰り返しが新しいリーダーになります。
- プローブ
-
監視は、他のモニターを探す場合はプロービング状態にあります。たとえば、Monitor を起動した後には、Monitor マップ
(monmap
)で指定された十分な Monitor を見つけてクォーラムを形成するまでプローブされます。 - electing
- リーダーの選択プロセスの場合、Monitor は選出の状態になります。通常、このステータスはすぐに変わります。
- 同期中
- クォーラムに参加するために他の Monitor と同期する場合は、Monitor が同期状態にあります。Monitor ストアが小さくなると、同期プロセスが速くなります。したがって、ストアが大きい場合は、同期に時間がかかります。
4.2. モニターマップの挿入
Monitor に古いモニターまたは破損した Monitor マップ(monmap
)がある場合、誤った IP アドレスの他の Monitor に到達しようとするため、クォーラムに参加することはできません。
この問題の最も安全な方法は、他の Monitor から実際の Monitor マップを取得して挿入することです。このアクションは Monitor によって保持される既存の Monitor マップを上書きすることに注意してください。
この手順では、他の Monitor がクォーラムを構成するか、1 つ以上の Monitor に正しい Monitor マップがある場合は Monitor マップを挿入する方法を説明します。すべての Monitor に破損したストアがあるため、Monitor マップもする場合は、「モニターストアのリカバリー」 を参照してください。
手順: モニターマップの挿入
残りの Monitor
がクォーラムを形成する場合は、ceph mon getmap
コマンドを使用して Monitor マップを取得します。# ceph mon getmap -o /tmp/monmap
残りの Monitor がクォーラムを形成できず、正しい Monitor マップでモニターが 1 つ以上ある場合は、その Monitor からコピーします。
Monitor マップをコピー元となる Monitor を停止します。
systemctl stop ceph-mon@<host-name>
たとえば、host1
の短縮ホスト名でホストで実行している Monitor を停止するには、次のコマンドを実行します。# systemctl stop ceph-mon@host1
Monitor マップをコピーします。
ceph-mon -i <id> --extract-monmap /tmp/monmap
<id>
を Monitor マップをコピーするモニターの ID に置き換えてください。以下に例を示します。# ceph-mon -i mon.a --extract-monmap /tmp/monmap
破損したモニターまたは古い Monitor マップでモニターを停止します。
systemctl stop ceph-mon@<host-name>
たとえば、host2
の短縮ホスト名を持つホストで実行している Monitor を停止するには、次のコマンドを実行します。# systemctl stop ceph-mon@host2
Monitor マップを注入します。
ceph-mon -i <id> --inject-monmap /tmp/monmap
<id>
を、Monitor の ID を破損したモニターまたは古い Monitor マップに置き換えます。以下に例を示します。# ceph-mon -i mon.c --inject-monmap /tmp/monmap
Monitor を起動します。以下に例を示します。
# systemctl start ceph-mon@host2
別の Monitor から Monitor マップをコピーした場合は、その Monitor を開始します。以下に例を示します。
# systemctl start ceph-mon@host1
関連項目
4.3. モニターストアのリカバリー
Ceph Monitors は、クラスターマップを LevelDB などのキーと値ストアに保存します。ストアが Monitor に破損した場合は、Monitor が予期せず終了し、再度起動に失敗します。Ceph ログには以下のエラーが含まれる場合があります。
Corruption: error in middle of record Corruption: 1 missing files; e.g.: /var/lib/ceph/mon/mon.0/store.db/1234567.ldb
実稼働クラスターは、少なくとも 3 つのモニターを使用し、失敗した場合は別のモニターと置き換えることができます。ただし、特定の状況では、Monitor にストアがすべて破損する可能性があります。たとえば、Monitor ノードが誤ってディスクまたはファイルシステムの設定を設定したと、電源の停止により、下層のファイルシステムが破損する可能性があります。
ストアがすべての Monitor に破損した場合は、ceph-monstore-tool および
。
ceph-objectstore-tool
という名前のユーティリティーを使用して、OSD ノードに保存されている情報で復元できます
この手順では、以下の情報を復元できません。
- Metadata Daemon Server(MDS)キーリングおよびマップ
配置グループの設定:
-
ceph pg set_full_ratio
コマンドを使用して設定するfull ratio
-
ceph pg set_nearfull_ratio
コマンドを使用して設定するほぼnearfull ratio
-
古いバックアップからモニターストアを復元しないでください。以下の手順に従って、現在のクラスター状態からモニターストアを再構築します。
作業を開始する前に
-
rsync
ユーティリティーおよびceph-test
パッケージがインストールされていることを確認します。
手順: モニターストアのリカバリー
破損したストアで Monitor ノードから以下のコマンドを使用します。
すべての OSD ノードからクラスターマップを収集します。
ms=<directory> mkdir $ms for host in $host_list; do rsync -avz "$ms" root@$host:"$ms"; rm -rf "$ms" ssh root@$host <<EOF for osd in /var/lib/ceph/osd/ceph-*; do ceph-objectstore-tool --data-path \$osd --op update-mon-db --mon-store-path $ms done EOF rsync -avz root@$host:$ms $ms; done
<directory>
を、収集したクラスターマップを保存する一時ディレクトリーに置き換えます。以下に例を示します。$ ms=/tmp/monstore/ $ mkdir $ms $ for host in $host_list; do rsync -avz "$ms" root@$host:"$ms"; rm -rf "$ms" ssh root@$host <<EOF for osd in /var/lib/ceph/osd/ceph-*; do ceph-objectstore-tool --data-path \$osd --op update-mon-db --mon-store-path $ms done EOF rsync -avz root@$host:$ms $ms; done
適切な機能を設定します。
ceph-authtool <keyring> -n mon. --cap mon 'allow *' ceph-authtool <keyring> -n client.admin --cap mon 'allow *' --cap osd 'allow *' --cap mds 'allow *'
<keyring>
をクライアント管理キーリングへのパスに置き換えます。以下に例を示します。$ ceph-authtool /etc/ceph/ceph.client.admin.keyring -n mon. --cap mon 'allow *' $ ceph-authtool /etc/ceph/ceph.client.admin.keyring -n client.admin --cap mon 'allow *' --cap osd 'allow *' --cap mds 'allow *'
収集したマップから Monitor ストアを再構築します。
ceph-monstore-tool <directory> rebuild -- --keyring <keyring>
<directory>
を最初のステップの一時ディレクトリーに、<keyring>
をクライアント管理キーリングへのパスに置き換えます。以下に例を示します。$ ceph-monstore-tool /tmp/mon-store rebuild -- --keyring /etc/ceph/ceph.client.admin.keyring
注記cephfx
認証を使用しない場合は、--keyring
オプションを省略します。$ ceph-monstore-tool /tmp/mon-store rebuild
破損したストアをバックアップします。
mv /var/lib/ceph/mon/<mon-ID>/store.db \ /var/lib/ceph/mon/<mon-ID>/store.db.corrupted
<mon-ID>
を Monitor ID に置き換えます(例:<mon.0>
)。# mv /var/lib/ceph/mon/mon.0/store.db \ /var/lib/ceph/mon/mon.0/store.db.corrupted
破損したストアを置き換えます。
mv /tmp/mon-store/store.db /var/lib/ceph/mon/<mon-ID>/store.db
<mon-ID>
を Monitor ID に置き換えます(例:<mon.0>
)。# mv /tmp/mon-store/store.db /var/lib/ceph/mon/mon.0/store.db
破損したストアを持つすべての Monitor に対してこの手順を繰り返します。
新しいストアの所有者を変更します。
chown -R ceph:ceph /var/lib/ceph/mon/<mon-ID>/store.db
<mon-ID>
を Monitor ID に置き換えます(例:<mon.0>
)。# chown -R ceph:ceph /var/lib/ceph/mon/mon.0/store.db
破損したストアを持つすべての Monitor に対してこの手順を繰り返します。
関連項目
4.4. 失敗したモニターの置き換え
Monitor に破損したストアがある場合、この問題を修正する方法は、Ansible 自動化アプリケーションを使用して Monitor を置き換えることです。
作業を開始する前に
- Monitor を削除する前に、他の Monitor が実行され、クォーラムを形成できるようにしてください。
手順: 失敗したモニターの置き換え
Monitor ホストから、デフォルトで
/var/lib/ceph/mon/<cluster-name>-<short-host-name>
にある Monitor ストアを削除します。rm -rf /var/lib/ceph/mon/<cluster-name>-<short-host-name>
Monitor ホストとクラスター名の短縮ホスト名を指定します。たとえば、
host1
で実行している Monitor の Monitor ストアを、remote
という名前のクラスターから削除するには、以下を実行します。# rm -rf /var/lib/ceph/mon/remote-host1
Monitor マップ (
monmap
) から Monitor を削除します。ceph mon remove <short-host-name> --cluster <cluster-name>
Monitor ホストとクラスター名の短縮ホスト名を指定します。たとえば、
host1
で実行しているモニターをremote
というクラスターから削除するには、以下を実行します。# ceph mon remove host1 --cluster remote
- 基盤のファイルシステムまたは Monitor ホストのハードウェアに関連する問題をトラブルシューティングおよび修正します。
Ansible 管理ノードから、Playbook
ceph-ansible
を実行してモニターを再デプロイします。$ /usr/share/ceph-ansible/ansible-playbook site.yml
関連項目
- 「モニターがクォーラム外である」
- Red Hat Ceph Storage 3 の『管理ガイド』の「 クラスターサイズの管理」の章
- Red Hat Enterprise Linux 向け 『Red Hat Ceph Storage 3 インストールガイド』の「Deploying Red HatCeph Storage」の章
4.5. モニターストアの圧縮
Monitor ストアのサイズが大きくなると、これを圧縮できます。
-
ceph tell
コマンドを使用して、動的にこれを使用します。詳細は、「モニターストアを動的に動作させる手順 」を参照してください。 -
ceph-mon
デーモンの起動時詳細は、「起動時のモニターストアの圧縮 」を参照してください。 -
ceph-mon
デーモンが稼働していない場合にceph-monstore-tool
を使用前述の方法が Monitor ストアを圧縮できない場合、または Monitor がクォーラムを超えていない状態で、そのログにCaught signal (Bus error)
エラーメッセージが含まれる場合は、この方法を使用してください。詳細は「ceph-monstore-tool
で Monitor Store のコンパイル」の手順を参照してください。
クラスターが active+clean
状態ではない場合やリバランスプロセスでストアサイズの変更を監視します。このため、リバランスの完了時に Monitor ストアを圧縮します。また、配置グループが active+clean
の状態であることを確認します。
手順: モニターストアを動的に圧縮する
ceph-mon
デーモンの実行中に Monitor ストアを圧縮するには、以下を実行します。
ceph tell mon.<host-name> compact
<host-name>
を ceph-mon
が実行されているホストの短縮ホスト名に置き換えます。不明な場合は hostname -s
コマンドを使用します。
# ceph tell mon.host1 compact
手順: 起動時にモニターストアの圧縮
[mon]
セクションの Ceph 設定に以下のパラメーターを追加します。[mon] mon_compact_on_start = true
ceph-mon
デーモンを再起動します。systemctl restart ceph-mon@<host-name>
<host-name>
を、デーモンが実行されているホストの短い名前に置き換えます。不明な場合はhostname -s
コマンドを使用します。# systemctl restart ceph-mon@host1
Monitor がクォーラムを形成することを確認します。
# ceph mon stat
- 必要に応じて、他の Monitor でこの手順を繰り返します。
手順: ceph-monstore-tool
でモニタリングストアの圧縮
開始する前に、ceph-test
パッケージがインストールされていることを確認します。
大型ストアを使用する
ceph-mon
デーモンが実行していないことを確認します。必要に応じてデーモンを停止します。systemctl status ceph-mon@<host-name> systemctl stop ceph-mon@<host-name>
<host-name>
を、デーモンが実行されているホストの短い名前に置き換えます。不明な場合はhostname -s
コマンドを使用します。# systemctl status ceph-mon@host1 # systemctl stop ceph-mon@host1
Monitor ストアを圧縮します。
ceph-monstore-tool /var/lib/ceph/mon/mon.<host-name> compact
<host-name>
を Monitor ホストの短縮ホスト名に置き換えます。# ceph-monstore-tool /var/lib/ceph/mon/mon.node1 compact
ceph-mon
を再度起動します。systemctl start ceph-mon@<host-name>
以下に例を示します。
# systemctl start ceph-mon@host1
関連項目
4.6. Ceph Manager のポートを開く
ceph-mgr
デーモンは、ceph-osd
デーモンと同じ範囲のポート範囲の OSD から配置グループ情報を受け取ります。これらのポートが開かない場合、クラスターは HEALTH_OK
から HEALTH_WARN
に展開し、PG が不明なパーセンテージで PG が unknown
なことを示します。
この状況を解決するには、ceph-mgr
デーモンを実行している各ホストでポート 6800:7300
を開きます。以下に例を示します。
[root@ceph-mgr] # firewall-cmd --add-port 6800:7300/tcp [root@ceph-mgr] # firewall-cmd --add-port 6800:7300/tcp --permanent
次に、ceph-mgr デーモンを再起動します
。
第5章 OSD のトラブルシューティング
本章では、Ceph OSD に関連する最も一般的なエラーを修正する方法を説明します。
作業を開始する前に
- ネットワーク接続を確認します。詳しくは、3章ネットワークの問題のトラブルシューティング を参照してください。
-
ceph health
コマンドを使用して、Monitors にクォーラムがあることを確認します。コマンドがヘルスステータス (HEALTH_OK
、HEALTH_WARN
、HEALTH_ERR
) を返すと、モニターはクォーラムを形成できます。そうでない場合には、モニターの問題が最初にアドレスされます。詳しくは、4章監視のトラブルシューティング を参照してください。Cephの正常性に関する詳細は
、「ceph health
コマンドの出力について」 を参照してください。 - 必要に応じて、リバランスプロセスを停止して、時間とリソースを保存します。詳しくは、「リバランスの停止および開始」 を参照してください。
5.1. OSD に関連する最も一般的なエラーメッセージ
以下の表には、ceph health detail
コマンドで返される、または Ceph ログに含まれる最も一般的なエラーメッセージを一覧表示しています。この表は、エラーを説明し、問題を修正するための特定の手順を示す対応するセクションへのリンクを提供します。
表5.1 OSD に関連するエラーメッセージ
エラーメッセージ | 参照 |
---|---|
| |
| |
| |
| |
| |
| |
|
表5.2 OSD に関連する Ceph Logs の一般的なエラーメッセージ
エラーメッセージ | ログファイル | 参照 |
---|---|---|
| 主なクラスターのログ | |
| 主なクラスターのログ | |
| 主なクラスターのログ | |
| OSD ログ | |
| OSD ログ |
5.1.1. フル OSD
ceph health detail
コマンドは、以下のようなエラーメッセージを返します。
HEALTH_ERR 1 full osds osd.3 is full at 95%
エラー内容:
Ceph は、クライアントが完全な OSD ノードで I/O 操作を実行しないようにし、データが失われるのを防ぎます。クラスターが mon_osd_full_ratio
パラメーターで設定された容量に達すると、HEALTH_ERR full osds
メッセージを返します。デフォルトでは、このパラメーターは 0.95
に設定されています。これはクラスター容量の 95% を意味します。
この問題を解決するには、以下を行います。
Raw ストレージのパーセント数 (%RAW USED
) を決定します。
# ceph df
%RAW USED
が 70-75% を超える場合は、以下を行うことができます。
- 不要なデータを削除します。これは、実稼働環境のダウンタイムを回避するための短期的なソリューションです。詳しくは、「フルクラスターからのデータの削除」 を参照してください。
- 新しい OSD ノードを追加してクラスターをスケーリングします。これは、Red Hat が推奨する長期的なソリューションです。詳細は、Red Hat Ceph Storage 3 の『管理ガイド』の 「OSD ノードの追加と削除 」の章を参照してください。
関連項目
5.1.2. Nearfull OSD
ceph health detail
コマンドは、以下のようなエラーメッセージを返します。
HEALTH_WARN 1 nearfull osds osd.2 is near full at 85%
エラー内容:
クラスターが mon osd nearfull ratio defaults
パラメーターで設定されている容量に到達すると、Ceph はほぼ nearfull osds
メッセージを返します。デフォルトでは、このパラメーターは 0.85
に設定されています。これはクラスター容量の 85% を意味します。
Ceph は、可能な限り最適な方法で CRUSH 階層に基づいてデータを分散しますが、同等の分散を保証することはできません。不均等なデータ分散と nearfull osds
メッセージの主な原因は次のとおりです。
- OSD は、クラスター内の OSD ノード間で分散されません。つまり、一部の OSD ノードは他のノードよりも大幅に複数の OSD をホストするか、CRUSH マップの一部の OSD の重みがそれらの容量に対して十分なわけではありません。
- 配置グループ(PG)数は、OSD の数、ユースケース、OSD ごとのターゲット PG、および OSD 使用率に従って適切ではありません。
- クラスターは不適切な CRUSH 設定を使用します。
- OSD のバックエンドストレージはほぼ満杯です。
この問題を解決するには、以下を行います。
- PG 数が十分にあることを確認し、必要に応じてこれを増やします。詳しくは、「PG 数の増加」 を参照してください。
- CRUSH tunable をクラスターバージョンに最適に使用していることを確認し、一致しない場合はそれらを調整します。詳細は、Red Hat Ceph Storage 3 の『Storage Strategies Guide』の 「CRUSH Tunables https://access.redhat.com/solutions/2159151 」セクションを参照し、「How can I test the impact CRUSH map tunable changes will have across OSD in Red Hat Ceph Storage?」を参照してください。
- 使用率別に OSD の重みを変更します。Red Hat Ceph Storage 3の『ストレージ戦略ガイド』の「OSDの重みの設定」セクションを参照してください 。
OSD で使用されるディスク上に残っている領域を決定します。
領域の OSD の一般的な数を表示するには、以下を実行します。
# ceph osd df
特定のノードで使用する領域の OSD 数を表示するには、以下のコマンドを実行します。
nearful
OSD が含まれるノードから以下のコマンドを使用します。$ df
- 必要な場合は、新規 OSD ノードを追加します。Red Hat Ceph Storage 3 の『管理ガイド』の 「OSD ノードの追加と削除 」の章を参照してください。
関連項目
5.1.3. 1 つ以上の OSD がダウンしている
ceph health
コマンドは、以下のようなエラーを返します。
HEALTH_WARN 1/3 in osds are down
エラー内容:
サービスの失敗やその他の OSD との通信に問題があるため、ceph-osd
プロセスの 1 つを利用することはできません。そのため、残りの ceph-osd
デーモンはこの失敗をモニターに報告していました。
ceph-osd
デーモンが実行していない場合は、基礎となる OSD ドライブまたはファイルシステムが破損しているか、またはキーリングが見つからないなどのその他のエラーにより、デーモンが起動しません。
ほとんどの場合、ネットワークの問題により、ceph-osd
デーモンが実行中にも down
とマークされている場合に状況が生じます。
この問題を解決するには、以下を行います。
down
になっている OSD を特定します。# ceph health detail HEALTH_WARN 1/3 in osds are down osd.0 is down since epoch 23, last address 192.168.106.220:6800/11080
ceph-osd
デーモンの再起動を試行します。systemctl restart ceph-osd@<OSD-number>
<OSD-number>
をダウンしている
OSD の ID に置き換えます。以下に例を示します。# systemctl restart ceph-osd@0
-
ceph-osd
」の手順に従ってください。を起動できない場合は、「ceph-osd
daemon cannot start -
ceph-osd
デーモンを起動できるがdown
とマークされている場合は、ceph-osd
デーモンが実行しているが、依然としてdown
とマークされている手順に従ってください。
-
ceph-osd
デーモンを起動できない
- 複数の OSD を含むノード(通常はそれ以上)がある場合は、デフォルトのスレッド数(PID 数)があれば十分であることを確認してください。詳しくは、「PID カウントの増加」 を参照してください。
OSD データおよびジャーナルパーティションが正しくマウントされていることを確認します。
# ceph-disk list ... /dev/vdb : /dev/vdb1 ceph data, prepared /dev/vdb2 ceph journal /dev/vdc : /dev/vdc1 ceph data, active, cluster ceph, osd.1, journal /dev/vdc2 /dev/vdc2 ceph journal, for /dev/vdc1 /dev/sdd1 : /dev/sdd1 ceph data, unprepared /dev/sdd2 ceph journal
ceph-disk
にアクティブとマークされた場合には
、パーティションがマウントされます。パーティションの準備が整っている場合は
、パーティションをマウントします。詳しくは、「OSD データパーティションのマウント」 を参照してください。パーティションの準備が不明な場合は、マウントの前に最初に準備する必要があります
。『Administration Guide Red Hat Ceph Storage 3』の「Preparing the OSD Data and Journal Drives 」セクションを参照してください。-
ERROR: missing keyring, cannot use cephx for authentication
が返された場合、OSD にはキーリングがありません。Red Hat Ceph Storage 3 の『管理ガイド』の「キーリング管理 」セクションを参照してください 。 ERROR: unable to open OSD superblock on /var/lib/ceph/osd/ceph-1
エラーメッセージが出力されると、ceph-osd
デーモンは基礎となるファイルシステムを読み込むことができません。このエラーをトラブルシューティングおよび修正する方法については、以下の手順を参照してください。注記OSD ホストのブート時にこのエラーメッセージが返される場合は、サポートチケットを開きます。これは、Red Hat Bugzilla 1439210 で追跡される既知の問題を示すためです。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。
対応するログファイルを確認して、障害の原因を特定します。デフォルトでは、Ceph はログファイルを
/var/log/ceph/
ディレクトリーに保存します。以下の
EIO
エラーメッセージのような EIO エラーメッセージは、基礎となるディスクの失敗を示しています。FAILED assert(!m_filestore_fail_eio || r != -5)
この問題を修正するには、基礎となる OSD ディスクを置き換えます。詳しくは、「OSD ドライブの置き換え」 を参照してください。
ログに、以下のような他の
FAILED assert
エラーが含まれる場合は、サポートチケットを作成してください。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。FAILED assert(0 == "hit suicide timeout")
dmesg
出力で、基礎となるファイルシステムまたはディスクのエラーを確認します。$ dmesg
error -5
エラーメッセージは、ベースとなる XFS ファイルシステムの破損を示しています。この問題を修正する方法は、Red Hat カスタマーポータルの「xfs_log_force: error -5 returned」のソリューション「What is the meaning of "xfs_log_force: error -5 returned」を参照してください。xfs_log_force: error -5 returned
-
dmesg
出力にSCSI エラーメッセージが含まれる場合は
、Red Hat カスタマーポータルの SCSI Error Codes Solution Finder ソリューションを参照し、問題を修正する最適な方法を判断してください。 - または、基礎となるファイルシステムを修正できない場合は、OSD ドライブを置き換えます。詳しくは、「OSD ドライブの置き換え」 を参照してください。
OSD がセグメンテーション違反で失敗した場合には、以下のようにセグメンテーション違反で失敗した場合には、必要な情報を収集してサポートチケットを作成します。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。
Caught signal (Segmentation fault)
ceph-osd
が実行中だが、down
とマークされている。
対応するログファイルを確認して、障害の原因を特定します。デフォルトでは、Ceph はログファイルを
/var/log/ceph/
ディレクトリーに保存します。ログに以下のようなエラーメッセージが含まれる場合は、「OSD のフラッピング」 を参照してください。
wrongly marked me down heartbeat_check: no reply from osd.2 since back
- 他のエラーが表示される場合は、サポートチケットを開きます。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。
関連項目
- 「OSD のフラッピング」
- 「古くなった配置グループ」
- Red Hat Ceph Storage 3 の『Administration Guide』の 「Starting, Stop, Stoping a Daemon by Instances 」セクションを参照してください。
5.1.4. OSD のフラッピング
ceph -w | grep osds
コマンドは、OSD を down
として繰り返し示し、短期間に再び up
します。
# ceph -w | grep osds 2017-04-05 06:27:20.810535 mon.0 [INF] osdmap e609: 9 osds: 8 up, 9 in 2017-04-05 06:27:24.120611 mon.0 [INF] osdmap e611: 9 osds: 7 up, 9 in 2017-04-05 06:27:25.975622 mon.0 [INF] HEALTH_WARN; 118 pgs stale; 2/9 in osds are down 2017-04-05 06:27:27.489790 mon.0 [INF] osdmap e614: 9 osds: 6 up, 9 in 2017-04-05 06:27:36.540000 mon.0 [INF] osdmap e616: 9 osds: 7 up, 9 in 2017-04-05 06:27:39.681913 mon.0 [INF] osdmap e618: 9 osds: 8 up, 9 in 2017-04-05 06:27:43.269401 mon.0 [INF] osdmap e620: 9 osds: 9 up, 9 in 2017-04-05 06:27:54.884426 mon.0 [INF] osdmap e622: 9 osds: 8 up, 9 in 2017-04-05 06:27:57.398706 mon.0 [INF] osdmap e624: 9 osds: 7 up, 9 in 2017-04-05 06:27:59.669841 mon.0 [INF] osdmap e625: 9 osds: 6 up, 9 in 2017-04-05 06:28:07.043677 mon.0 [INF] osdmap e628: 9 osds: 7 up, 9 in 2017-04-05 06:28:10.512331 mon.0 [INF] osdmap e630: 9 osds: 8 up, 9 in 2017-04-05 06:28:12.670923 mon.0 [INF] osdmap e631: 9 osds: 9 up, 9 in
また、Ceph ログに以下のようなエラーメッセージが含まれます。
2016-07-25 03:44:06.510583 osd.50 127.0.0.1:6801/149046 18992 : cluster [WRN] map e600547 wrongly marked me down
2016-07-25 19:00:08.906864 7fa2a0033700 -1 osd.254 609110 heartbeat_check: no reply from osd.2 since back 2016-07-25 19:00:07.444113 front 2016-07-25 18:59:48.311935 (cutoff 2016-07-25 18:59:48.906862)
エラー内容:
OSD のフラッピングの主な原因は以下のとおりです。
- スクラビングやリカバリーなどの一部のクラスター操作は異常の時間がかかります。たとえば、大規模なインデックスまたは大きい配置グループを持つオブジェクトに対してこれらの操作を実行します。通常、これらの操作が完了すると、フラッピング OSD の問題が解決されます。
-
基礎となる物理ハードウェアに関する問題。この場合、
ceph health details
コマンドもslow requests
エラーメッセージを返します。詳細は 「遅いリクエスト、および要求はブロックされます。」 を参照してください。 - ネットワークに関する問題。
パブリック(フロントエンド)ネットワークが最適に動作している間に、OSD はクラスター(バックエンド)ネットワークに障害が発生したり、重要なレイテンシーを開発する場合、OSD は適切ではありません。
OSD はハートビートパケットを相互に送信するためにクラスターネットワークを使用し、それらが up
で in
であることを示します。クラスターネットワークが適切に機能しない場合、OSD はハートビートパケットの送受信を行いません。その結果、これらはお互いをモニターに down
していると報告し、それ自体を up
とマークします。
Ceph 設定ファイルの以下のパラメーターにより、この動作に影響があります。
パラメーター | 説明 | デフォルト値 |
---|---|---|
|
ハートビートパケットが OSD をモニターへの | 20 秒 |
|
Monitors が OSD を | 2 |
この表は、デフォルト設定の Ceph Monitor は 1 つの OSD のみで、最初の OSD が停止していることを
3 つの異なるレポートした場合に、OSD を down
とマークすることを示しています。1 つのホストがネットワークの問題が発生した場合、クラスター全体が OSD をフラッピングする可能性があります。これは、ホスト上に存在する OSD が、クラスター内の他の OSD を down
として報告するためです。
OSD プロセスの起動後、すぐに強制終了される OSD のシナリオには、OSD のシナリオは含まれません。
この問題を解決するには、以下を行います。
ceph health detail
コマンドの出力を再度確認します。遅いリクエストエラーメッセージが含まれている場合は
、「遅いリクエスト、および要求はブロックされます。」 でこの問題のトラブルシューティング方法を参照してください。# ceph health detail HEALTH_WARN 30 requests are blocked > 32 sec; 3 osds have slow requests 30 ops are blocked > 268435 sec 1 ops are blocked > 268435 sec on osd.11 1 ops are blocked > 268435 sec on osd.18 28 ops are blocked > 268435 sec on osd.39 3 osds have slow requests
down
としてマークされている OSD と、その OSD が置かれているノードを判別します。# ceph osd tree | grep down
- フラッピング OSD を含むノードで、ネットワークの問題をトラブルシューティングおよび修正します。詳細は 3章ネットワークの問題のトラブルシューティング を参照してください。
noup
フラグおよびnodown
フラグを設定して、OSD をdown
およびup
としてマークするのを停止するための一時的な強制モニターを実行できます。# ceph osd set noup # ceph osd set nodown
重要noup
フラグおよびnodown
フラグを使用しても、問題の根本的な原因は修正されず、OSD がフラッピングしないようにします。サポートチケットを作成してください。解決できない場合は、ご自身でエラーを修正してトラブルシューティングしてください。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。-
さらに、フラッピング OSD は、Ceph 設定ファイルで
osd heartbeat min size = 100
を設定し、OSD を再起動することで修正できます。これにより、MTU の誤設定が原因でネットワークの問題が解決されます。
関連情報
- Red Hat Ceph Storage 3 インストールガイド for Red HatEnterprise Linux またはUbuntu の場合は、『Red Hat Ceph Storage 3 インストールガイド』の「ネットワーク設定の確認 」セクションを参照してください。
- Red Hat Ceph Storage 3 の『アーキテクチャーガイド』の「Heartbeat ing 」セクション
5.1.5. 遅いリクエスト、および要求はブロックされます。
ceph-osd
デーモンは要求に応答するのに時間がかかり、ceph health detail
コマンドは以下のようなエラーメッセージを返します。
HEALTH_WARN 30 requests are blocked > 32 sec; 3 osds have slow requests 30 ops are blocked > 268435 sec 1 ops are blocked > 268435 sec on osd.11 1 ops are blocked > 268435 sec on osd.18 28 ops are blocked > 268435 sec on osd.39 3 osds have slow requests
また、Ceph ログには、以下のようなエラーメッセージが表示されます。
2015-08-24 13:18:10.024659 osd.1 127.0.0.1:6812/3032 9 : cluster [WRN] 6 slow requests, 6 included below; oldest blocked for > 61.758455 secs
2016-07-25 03:44:06.510583 osd.50 [WRN] slow request 30.005692 seconds old, received at {date-time}: osd_op(client.4240.0:8 benchmark_data_ceph-1_39426_object7 [write 0~4194304] 0.69848840) v4 currently waiting for subops from [610]
エラー内容:
要求が遅い OSD は、osd_op_complaint_time
パラメーターで定義される時間内にキュー内の 1 秒あたりの I/O 操作 (IOPS) を処理しないすべての OSD です。デフォルトでは、このパラメーターは 30 秒に設定されています。
OSD の主に要求の速度が遅いことが原因は以下の通りです。
- ディスクドライブ、ホスト、ラック、ネットワークスイッチなどの基礎となるハードウェアに関する問題
- ネットワークに関する問題。通常、これらの問題はフラッピング OSD に接続されています。詳しくは、「OSD のフラッピング」 を参照してください。
- システムの負荷
以下の表は、遅いリクエストのタイプを示しています。dump_historic_ops
管理ソケットコマンドを使用して、低速な要求のタイプを判断します。管理ソケットの詳細は、Red Hat Ceph Storage 3 の『管理ガイド』の「管理ソケットの使用 」セクションを参照してください。
遅い要求タイプ | 詳細 |
---|---|
| OSD は、操作の配置グループでロックを取得するまで待機します。 |
| OSD は、レプリカ OSD が操作をジャーナルに適用するまで待機しています。 |
| OSD は、主要な操作マイルストーンに到達しませんでした。 |
| OSD は、指定した回数だけオブジェクトを複製していません。 |
この問題を解決するには、以下を行います。
- 遅い要求またはブロック要求のある OSD がハードウェアの一般的な部分(ディスクドライブ、ホスト、ラック、ネットワークスイッチなど)を共有するかどうかを判別します。
OSD がディスクを共有する場合は、以下を実行します。
smartmontools
ユーティリティーを使用して、ディスクまたはログの状態をチェックして、ディスクのエラーを確認します。注記smartmontools
ユーティリティーは、smartmontools
パッケージに含まれています。iostat
ユーティリティーを使用して OSD ディスクの I/O 待機レポート (%iowai
) を取得し、ディスク負荷が大きいかどうかを判断します。注記iostat
ユーティリティーは、sysstat
パッケージに含まれています。
OSD がホストを共有している場合は、以下を実行します。
- RAM および CPU 使用率を確認します。
-
netstat
ユーティリティーを使用して、ネットワークインターフェースコントローラー (NIC) のネットワーク統計を確認し、ネットワークの問題のトラブルシューティングを行います。詳細は、3章ネットワークの問題のトラブルシューティング も参照してください。
- OSD がラックを共有している場合は、ラックのネットワークスイッチを確認します。たとえば、ジャンボフレームを使用する場合は、パスの NIC にジャンボフレームが設定されていることを確認してください。
- 遅い要求で OSD によって共有されるハードウェアの一部を判別できない場合、またはハードウェアおよびネットワーク問題のトラブルシューティングおよび修正を行うには、サポートチケットを作成してください。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。
関連項目
- Red Hat Ceph Storage 3 の『管理ガイド』の「管理 https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/3/html-single/administration_guide/#using_the_administration_socket ソケットの使用 」セクション
5.2. リバランスの停止および開始
OSD の失敗や停止時に、CRUSH アルゴリズムはリバランスプロセスを自動的に開始し、残りの OSD 間でデータを再分配します。
リバランスには時間とリソースを取るため、トラブルシューティング中または OSD のメンテナンス時のリバランスについて検討してください。これを行うには、OSD を停止する前に noout
フラグを設定します。
# ceph osd set noout
トラブルシューティングまたはメンテナンスが完了したら、noout
フラグの設定を解除して、リバランスを開始します。
# ceph osd unset noout
トラブルシューティングおよびメンテナンス時に、停止された OSD 内の配置グループは degraded
します。
関連項目
- Red Hat Ceph Storage 3 の『アーキテクチャーガイド』の「リバランス およびリカバリー 」セクション
5.3. OSD データパーティションのマウント
OSD データパーティションが正しくマウントされていない場合は、ceph-osd
デーモンを起動することができません。パーティションが想定どおりにマウントされていないことを検出する場合は、本セクションの手順に従ってマウントします。
手順: OSD データパーティションのマウント
パーティションをマウントします。
# mount -o noatime <partition> /var/lib/ceph/osd/<cluster-name>-<osd-number>
<partition>
を、OSD データ専用の OSD ドライブ上のパーティションへのパスに置き換えます。クラスター名と OSD 番号を指定します。以下に例を示します。# mount -o noatime /dev/sdd1 /var/lib/ceph/osd/ceph-0
失敗した
ceph-osd
デーモンの起動を試みます。# systemctl start ceph-osd@<OSD-number>
<OSD-number>
を OSD の ID に置き換えます。以下に例を示します。# systemctl start ceph-osd@0
関連項目
5.4. OSD ドライブの置き換え
Ceph は耐障害性を確保できるように設計されているため、データを損失せずに動作が degraded
の状態になっています。そのため、データストレージドライブが失敗しても、Ceph は動作させることができます。障害が発生したドライブのコンテキストでは、パフォーマンスが degraded
した状態は、他の OSD に保存されているデータの追加コピーが、クラスター内の他の OSD に自動的にバックフィルされることを意味します。ただし、これが発生した場合には、障害のある OSD ドライブを置き換え、OSD を手動で再作成します。
ドライブに障害が発生すると、Ceph は OSD を down
として報告します。
HEALTH_WARN 1/3 in osds are down osd.0 is down since epoch 23, last address 192.168.106.220:6800/11080
Ceph は、ネットワークやパーミッションの問題により OSD を down
とマークすることもできます。詳しくは、「1 つ以上の OSD がダウンしている」 を参照してください。
現代のサーバーは通常、ホットスワップ可能なドライブでデプロイされるので、障害が発生したドライブをプルして、ノードを停止せずに新しいドライブに置き換えることができます。手順全体には、以下の手順が含まれます。
- Ceph クラスターから OSD を削除します。詳細は、「Ceph クラスターからの OSD の削除」の手順を参照してください。
- ドライブを置き換えます。詳細は「物理ドライブの置き換え」セクションを参照してください。
- OSD をクラスターに追加します。詳細は、「OSD の Ceph クラスターへの追加 」の手順を参照してください。
作業を開始する前に
down
になっている OSD を特定します。# ceph osd tree | grep -i down ID WEIGHT TYPE NAME UP/DOWN REWEIGHT PRIMARY-AFFINITY 0 0.00999 osd.0 down 1.00000 1.00000
OSD プロセスが停止していることを確認します。OSD ノードから以下のコマンドを使用します。
# systemctl status ceph-osd@<OSD-number>
<OSD-number>
をdown
とマークされた OSD の ID に置き換えます。以下に例を示します。# systemctl status ceph-osd@osd.0 ... Active: inactive (dead)
ceph-osd
デーモンが実行しているかどうか。ダウンとマークされているが
、対応するceph-osd
デーモンが実行されている OSD のトラブルシューティングについての詳しい情報は、「1 つ以上の OSD がダウンしている」 を参照してください。
手順: Ceph クラスターからの OSD の削除
OSD を
out
としてマークを付けます。# ceph osd out osd.<OSD-number>
<OSD-number>
をdown
とマークされた OSD の ID に置き換えます。以下に例を示します。# ceph osd out osd.0 marked out osd.0.
注記OSD
がダウンしている場合
、Ceph は OSD からハートビートパケットを受信しない場合に 600秒後に自動的にマークします
。これが発生すると、失敗した OSD データのコピーを持つ他の OSD がバックフィルを開始し、必要なコピー数がクラスター内で存在することを確認します。クラスターがバックフィル状態である間、クラスターの状態はdegraded
します。失敗した OSD がバックフィルされていることを確認します。出力には、以下のような情報が含まれます。
# ceph -w | grep backfill 2017-06-02 04:48:03.403872 mon.0 [INF] pgmap v10293282: 431 pgs: 1 active+undersized+degraded+remapped+backfilling, 28 active+undersized+degraded, 49 active+undersized+degraded+remapped+wait_backfill, 59 stale+active+clean, 294 active+clean; 72347 MB data, 101302 MB used, 1624 GB / 1722 GB avail; 227 kB/s rd, 1358 B/s wr, 12 op/s; 10626/35917 objects degraded (29.585%); 6757/35917 objects misplaced (18.813%); 63500 kB/s, 15 objects/s recovering 2017-06-02 04:48:04.414397 mon.0 [INF] pgmap v10293283: 431 pgs: 2 active+undersized+degraded+remapped+backfilling, 75 active+undersized+degraded+remapped+wait_backfill, 59 stale+active+clean, 295 active+clean; 72347 MB data, 101398 MB used, 1623 GB / 1722 GB avail; 969 kB/s rd, 6778 B/s wr, 32 op/s; 10626/35917 objects degraded (29.585%); 10580/35917 objects misplaced (29.457%); 125 MB/s, 31 objects/s recovering 2017-06-02 04:48:00.380063 osd.1 [INF] 0.6f starting backfill to osd.0 from (0'0,0'0] MAX to 2521'166639 2017-06-02 04:48:00.380139 osd.1 [INF] 0.48 starting backfill to osd.0 from (0'0,0'0] MAX to 2513'43079 2017-06-02 04:48:00.380260 osd.1 [INF] 0.d starting backfill to osd.0 from (0'0,0'0] MAX to 2513'136847 2017-06-02 04:48:00.380849 osd.1 [INF] 0.71 starting backfill to osd.0 from (0'0,0'0] MAX to 2331'28496 2017-06-02 04:48:00.381027 osd.1 [INF] 0.51 starting backfill to osd.0 from (0'0,0'0] MAX to 2513'87544
CRUSH マップから OSD を削除します。
# ceph osd crush remove osd.<OSD-number>
<OSD-number>
をdown
とマークされた OSD の ID に置き換えます。以下に例を示します。# ceph osd crush remove osd.0 removed item id 0 name 'osd.0' from crush map
OSD に関連する認証キーを削除します。
# ceph auth del osd.<OSD-number>
<OSD-number>
をdown
とマークされた OSD の ID に置き換えます。以下に例を示します。# ceph auth del osd.0 updated
Ceph Storage クラスターから OSD を削除します。
# ceph osd rm osd.<OSD-number>
<OSD-number>
をdown
とマークされた OSD の ID に置き換えます。以下に例を示します。# ceph osd rm osd.0 removed osd.0
OSD を正常に削除している場合は、以下のコマンドの出力には存在しません。
# ceph osd tree
障害が発生したドライブをアンマウントします。
# umount /var/lib/ceph/osd/<cluster-name>-<OSD-number>
クラスターの名前と OSD の ID を指定します。以下に例を示します。
# umount /var/lib/ceph/osd/ceph-0/
ドライブを正常にマウントした場合は、次のコマンドの出力には存在しません。
# df -h
手順: 物理ドライブの置き換え
物理ドライブの置き換えに関する詳細は、ハードウェアノードのドキュメントを参照してください。
- ドライブがホットスワップできない場合は、障害が発生したドライブを新しいドライブに置き換えます。
- ドライブがホットスワップ可能で、ノードに複数の OSD が含まれる場合は、ノード全体をシャットダウンし、物理ドライブを置き換える必要がある場合があります。クラスターのバックフィルを防止することを検討してください。詳しくは、「リバランスの停止および開始」 を参照してください。
-
ドライブが
/dev/
ディレクトリー配下に表示されたら、ドライブパスを書き留めます。 - OSD を手動で追加する必要がある場合には、OSD ドライブを見つけ、ディスクをフォーマットします。
手順: OSD の Ceph クラスターへの追加
OSD を再度追加します。
Ansible を使用してクラスターをデプロイしている場合は、Ceph 管理サーバーから Playbook
ceph-ansible
を再度実行します。# ansible-playbook /usr/share/ceph-ansible site.yml
- OSD を手動で追加している場合は、Red Hat Ceph Storage 3 の _Administration Guid_e の「コマンドラインインターフェースを使用した OSD の追加 」セクションを参照してください。
CRUSH 階層が正確であることを確認します。
# ceph osd tree
CRUSH 階層の OSD の場所が分からない場合は、OSD を任意の場所に移動します。
ceph osd crush move <bucket-to-move> <bucket-type>=<parent-bucket>
たとえば、
sdd:row1
にあるバケットを root バケットに移動するには、以下を実行します。# ceph osd crush move ssd:row1 root=ssd:root
関連項目
- 「1 つ以上の OSD がダウンしている」
- Red Hat Ceph Storage 3 の『管理ガイド』の「 クラスターサイズの管理」の章
- Red Hat Ceph Storage 3インストールガイド(Red Hat Enterprise Linux 用 ) またはUbuntu のインストールガイド
5.5. PID カウントの増加
1 つ以上の Ceph OSD を含むノードがある場合、特にリカバリー時に、デフォルトの最大スレッド数(PID 数)は不十分になります。これにより、一部の ceph-osd
デーモンが終了して再起動に失敗する可能性があります。その場合は、許容されるスレッドの最大数を増やします。
一時的に数字を増やすには、以下を実行します。
# sysctl -w kernel.pid.max=4194303
数値を永続的に増やすには、以下のように /etc/sysctl.conf
ファイルを更新します。
kernel.pid.max = 4194303
5.6. フルクラスターからのデータの削除
Ceph は、mon_osd_full_ratio
パラメーターで指定された容量に到達した OSD の I/O 操作を自動的に防ぎ、full osds
エラーメッセージを返します。
この手順では、このエラーを修正するために不要なデータを削除する方法を説明します。
mon_osd_full_ratio
パラメーターは、クラスターの作成時に full_ratio
パラメーターの値を設定します。その後は、mon_osd_full_ratio
の値を変更することはできません。full_ratio
値を一時的に増やすには、代わりに set-full-ratio
を増やします。
手順: フルクラスターからのデータの削除
full_ratio
の現在の値を判別します。デフォルトでは0.95
に設定されます。# ceph osd dump | grep -i full full_ratio 0.95
set-full-ratio
を0.97
に設定して、値を一時的に増やします。# ceph osd set-full-ratio 0.97
重要Red Hat は、
set-full-ratio
を 0.97 を超える値に設定しないことを強く推奨します。このパラメーターを高い値に設定すると、リカバリープロセスが難しくなります。したがって、OSD をまったく復元できない場合があります。パラメーターを
0.97
に正常に設定していることを確認します。# ceph osd dump | grep -i full full_ratio 0.97
クラスターの状態を監視します。
# ceph -w
クラスターの状態が
full
からnearfull
に変わると、不要なデータが削除されます。full_ratio
の値を0.95
に設定します。# ceph osd set-full-ratio 0.95
パラメーターを
0.95
に正常に設定していることを確認します。# ceph osd dump | grep -i full full_ratio 0.95
関連項目
第6章 マルチサイト Ceph Object Gateway のトラブルシューティング
本章では、マルチサイト Ceph Object Gateway の設定および運用状態に関連する最も一般的なエラーを修正する方法を説明します。
6.1. 前提条件
- 稼働中の Red Hat Ceph Storage 3 環境。
- 実行中の Ceph Object Gateway。
6.2. Ceph Object Gateway のエラーコード定義
Ceph Object Gateway ログには、お使いの環境のトラブルシューティングに役立つエラーおよび警告メッセージが含まれます。一般的なものは、推奨される解決策で以下に挙げられています。その他のサポートは、Red Hat サポート にお問い合わせください。
一般的なエラーメッセージ
data_sync: ERROR: a sync operation returned error
- これは、低レベルのバケット同期プロセスでエラーが返されることを説明します。このメッセージは冗長になっています。バケットの同期エラーがログに表示されます。
データ同期: ERROR: failed to sync object: <bucket name>:<object name>
- プロセスがリモートゲートウェイから HTTP 経由で必要なオブジェクトの取得に失敗したか、またはそのオブジェクトを RADOS への書き込みに失敗したプロセスも、再度試行されます。
data sync: ERROR: failure in sync, backing out (sync_status=2)
-
上記の条件の 1 つを反映した低レベルのメッセージ。同期前にデータが削除され、
-2 ENOENT
ステータスが表示されます。 data sync: ERROR: failure in sync, backing out (sync_status=-5)
-
上記の条件の 1 つを反映した低レベルのメッセージ。特に、そのオブジェクトを RADOS に書き込みに失敗し、
-5 EIO
が示されます。 ERROR: failed to fetch remote data log info: ret=11
-
これは、別のゲートウェイからのエラー状態を反映した
libcurl
のEAGAIN
汎用エラーコードです。デフォルトでは再度試行されます。 meta sync: ERROR: failed to read mdlog info with (2) No such file or directory
- mdlog のシャードが作成されず、同期は何もありません。
エラーメッセージの同期
failed to sync object
- プロセスがリモートゲートウェイから HTTP 経由でこのオブジェクトの取得に失敗したか、またはそのオブジェクトを RADOS への書き込みに失敗し、再度試行されます。
failed to sync bucket instance: (11) Resource temporarily unavailable
- プライマリーゾーンとセカンダリーゾーン間の接続の問題。
failed to sync bucket instance: (125) Operation canceled
- 同じ RADOS オブジェクトへの書き込みの間には、Racing 条件が存在します。
6.3. マルチサイト Ceph Object Gateway の同期
マルチサイトの同期は、他のゾーンから変更ログを読み取ります。メタデータおよびデータループから同期の進捗の概要を表示するには、以下のコマンドを使用できます。
radosgw-admin sync status
このコマンドは、ソースゾーンの背後にあるログシャードの一覧を表示します。
上記で実行した同期ステータスの結果がログシャードのレポートより遅れている場合は、shard-id を X に置き換えて次のコマンドを実行します。
radosgw-admin data sync status --shard-id=X
- 置換...
- X はシャードの ID 番号に置き換えます。
例
[root@rgw ~]# radosgw-admin data sync status --shard-id=27 { "shard_id": 27, "marker": { "status": "incremental-sync", "marker": "1_1534494893.816775_131867195.1", "next_step_marker": "", "total_entries": 1, "pos": 0, "timestamp": "0.000000" }, "pending_buckets": [], "recovering_buckets": [ "pro-registry:4ed07bb2-a80b-4c69-aa15-fdc17ae6f5f2.314303.1:26" ] }
出力には、次に同期されるバケットと、以前のエラーによりリトライされるバケットが表示されます。
X をバケット ID に置き換えて、次のコマンドを使用して個々のバケットのステータスを検査します。
radosgw-admin bucket sync status --bucket=X.
- 置換...
- x はバケットの ID 番号に置き換えます。
その結果、バケットインデックスログシャードがソースゾーンの背後にあることが表示されます。
同期の一般的なエラーは EBUSY
です。これは同期がすでに進行中であることを意味します。多くの場合は別のゲートウェイで行われます。同期エラーログへ書き込まれたエラーを読み取ります。これは、以下のコマンドで読み込むことができます。
radosgw-admin sync error list
同期プロセスは成功するまで再試行します。エラーは、介入が必要になる可能性があります。
6.3.1. マルチサイトの Ceph Object Gateway データ同期のパフォーマンスカウンター
データ同期を測定するために、以下のパフォーマンスカウンターを Ceph Object Gateway のマルチサイト設定に使用できます。
-
poll_latency
は、リモートレプリケーションログに対する要求のレイテンシーを測定します。 -
fetch_bytes
は、データ同期によってフェッチされるオブジェクト数およびバイト数を測定します。
ceph デーモン .. perf dump
コマンドを使用して、パフォーマンスカウンターの現在のメトリックデータを表示します。
# ceph daemon /var/run/ceph/{rgw}.asok
出力例:
{ "data-sync-from-us-west": { "fetch bytes": { "avgcount": 54, "sum": 54526039885 }, "fetch not modified": 7, "fetch errors": 0, "poll latency": { "avgcount": 41, "sum": 2.533653367, "avgtime": 0.061796423 }, "poll errors": 0 } }
デーモンを実行するノードから ceph daemon
コマンドを実行する必要があります。
関連情報
- パフォーマンスカウンターの詳細は、『Administration Guide for Red Hat Ceph Storage 3』の「Performance Counters 」セクションを参照してください。
第7章 配置グループのトラブルシューティング
本項では、Ceph Placement Groups(PG)に関連する最も一般的なエラーを修正する方法を説明します。
作業を開始する前に
- ネットワーク接続を確認します。詳しくは、3章ネットワークの問題のトラブルシューティング を参照してください。
- Monitor がクォーラムを形成するようにします。Monitor に関連する最も一般的なエラーのトラブルシューティングについては、4章監視のトラブルシューティング を参照してください。
-
すべての正常な OSD が
up
してin
であり、バックフィルおよびリカバリープロセスが完了したことを確認します。OSD に関連する最も一般的なエラーのトラブルシューティングについては、5章OSD のトラブルシューティング を参照してください。
7.1. Placement グループに関連する最も一般的なエラーメッセージ
以下の表では、ceph health details
コマンドで返される最も一般的なエラーメッセージを一覧表示しています。以下の表には、エラーを説明し、問題を修正するための特定の手順を説明する対応するセクションへのリンクが記載されています。
さらに、最適な状態ではない状態のままの配置グループを一覧表示することもできます。詳しくは、「配置グループが stale
、inactive
、または unclean State での一覧表示
」 を参照してください。
表7.1 配置グループに関連するエラーメッセージ
エラーメッセージ | 参照 |
---|---|
| |
| |
| |
| |
| |
| |
|
7.1.1. 古くなった配置グループ
ceph health
コマンドは、一部の配置グループ (PG) を stale
一覧で表示します。
HEALTH_WARN 24 pgs stale; 3/300 in osds are down
エラー内容:
モニターは、配置グループが動作しているセットのプライマリー OSD からステータスの更新を受け取らない場合や、プライマリー OSD が down
していると他の OSD が報告されない場合に、配置グループを stale
とマークします。
通常、PG はストレージクラスターを起動し、ピアリングプロセスが完了するまで、stale
状態になります。ただし、PG が想定よりも stale
である (古くなっている) 場合は、PG のプライマリー OSD が ダウン
しているか、または PG 統計をモニターに報告していないことを示す可能性があります。古い
PG を保存するプライマリー OSD が up
に戻ると、Ceph は PG の復元を開始します。
mon_osd_report_timeout
の設定は、OSD が PG の統計をモニターに報告する頻度を決定します。デフォルトでは、このパラメーターは 0.5
に設定されています。これは、OSD が 0.5 秒ごとに統計を報告することを意味します。
この問題を解決するには、以下を行います。
古い
PG とそれらが保存される OSD を特定します。エラーメッセージには、以下の例のような情報が含まれます。# ceph health detail HEALTH_WARN 24 pgs stale; 3/300 in osds are down ... pg 2.5 is stuck stale+active+remapped, last acting [2,0] ... osd.10 is down since epoch 23, last address 192.168.106.220:6800/11080 osd.11 is down since epoch 13, last address 192.168.106.220:6803/11539 osd.12 is down since epoch 24, last address 192.168.106.220:6806/11861
-
down
とマークされている OSD の問題のトラブルシューティング。詳細は 「1 つ以上の OSD がダウンしている」 を参照してください。
関連項目
- 『Red Hat Ceph Storage 3 の管理ガイド』の 「{administration-guide}#identifying_troubled_placement_groups[Monitoring Placement Group States]」セクション
7.1.2. 一貫性のない配置グループ
一部の配置グループは active + clean + inconsistent
とマークされ、ceph health detail
は以下のようなエラーメッセージを返します。
HEALTH_ERR 1 pgs inconsistent; 2 scrub errors pg 0.6 is active+clean+inconsistent, acting [0,1,2] 2 scrub errors
エラー内容:
Ceph は、配置グループ内のオブジェクトの 1 つ以上のレプリカで不整合を検出すると、配置グループに inconsistent
のマークを付けます。最も一般的な不整合は以下のとおりです。
- オブジェクトのサイズが正しくありません。
- 復旧完了後にあるレプリカにオブジェクトがありません。
多くの場合、スクラビング時のエラーが発生すると、配置グループ内で不整合が生じます。
この問題を解決するには、以下を行います。
どの配置グループが
一貫性のない
状態かを決定します。# ceph health detail HEALTH_ERR 1 pgs inconsistent; 2 scrub errors pg 0.6 is active+clean+inconsistent, acting [0,1,2] 2 scrub errors
配置グループに
inconsistent
な理由を決定します。配置グループでディープスクラビングプロセスを開始します。
ceph pg deep-scrub <id>
<id>
を、一貫性のない配置グループの
ID に置き換えます。以下に例を示します。# ceph pg deep-scrub 0.6 instructing pg 0.6 on osd.0 to deep-scrub
ceph -w
の出力で、その配置グループに関連するメッセージを探します。ceph -w | grep <id>
<id>
を、一貫性のない配置グループの
ID に置き換えます。以下に例を示します。# ceph -w | grep 0.6 2015-02-26 01:35:36.778215 osd.106 [ERR] 0.6 deep-scrub stat mismatch, got 636/635 objects, 0/0 clones, 0/0 dirty, 0/0 omap, 0/0 hit_set_archive, 0/0 whiteouts, 1855455/1854371 bytes. 2015-02-26 01:35:36.788334 osd.106 [ERR] 0.6 deep-scrub 1 errors
出力に以下のようなエラーメッセージが含まれる場合は、
inconsistent
配置グループを修復できます。詳しくは、「配置グループの修復」 を参照してください。<pg.id> shard <osd>: soid <object> missing attr _, missing attr <attr type> <pg.id> shard <osd>: soid <object> digest 0 != known digest <digest>, size 0 != known size <size> <pg.id> shard <osd>: soid <object> size 0 != known size <size> <pg.id> deep-scrub stat mismatch, got <mismatch> <pg.id> shard <osd>: soid <object> candidate had a read error, digest 0 != known digest <digest>
出力に以下のようなエラーメッセージが含まれる場合は、データが失われる可能性があるため、
inconsistent
のない配置グループを修正しても安全ではありません。この場合、サポートチケットを作成します。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。<pg.id> shard <osd>: soid <object> digest <digest> != known digest <digest> <pg.id> shard <osd>: soid <object> omap_digest <digest> != known omap_digest <digest>
関連項目
- 「配置グループの修復」
- 「包含の一覧表示」
- 『Red Hat Ceph Storage 3 Architecture Guide』の「Enuring https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/3/html-single/architecture_guide/#concept-arch-data-integrity-arch Data Integrity 」セクション
- Red Hat Ceph Storage 3 の『設定ガイド』の「スクラビング 」セクション
7.1.3. 配置グループが適切に行われない
ceph health
コマンドは、以下のようなエラーメッセージを返します。
HEALTH_WARN 197 pgs stuck unclean
エラー内容:
Ceph 設定ファイルの mon_pg_stuck_threshold
パラメーターで指定された秒数について、active+clean
の状態を満たさない場合には、Ceph 配置グループは unclean
とマーク付けされます。mon_pg_stuck_threshold
のデフォルト値は 300
秒です。
配置グループが unclean
である場合は、osd_pool_default_size
パラメーターで指定された回数複製されないオブジェクトが含まれます。osd_pool_default_size
のデフォルト値は 3
で、Ceph はレプリカを 3 つ作成します。
通常、unclean
配置グループは、一部の OSD が down
している可能性があることを意味します。
この問題を解決するには、以下を行います。
down
になっている OSD を特定します。# ceph osd tree
- OSD 関連の問題のトラブルシューティングと修正を行います。詳しくは、「1 つ以上の OSD がダウンしている」 を参照してください。
関連項目
7.1.4. 非アクティブな配置グループ
ceph health
コマンドは、以下のようなエラーメッセージを返します。
HEALTH_WARN 197 pgs stuck inactive
エラー内容:
Ceph 設定ファイルの mon_pg_stuck_threshold
パラメーターで指定された秒数について、配置グループが非表示になっていない場合、Ceph はその配置グループを inactive
とマークします。mon_pg_stuck_threshold
のデフォルト値は 300
秒です。
通常、inactive
な配置グループは一部の OSD が down
となっている可能性があることを示します。
この問題を解決するには、以下を行います。
down
になっている OSD を特定します。# ceph osd tree
- OSD 関連の問題のトラブルシューティングと修正を行います。詳しくは、「1 つ以上の OSD がダウンしている」 を参照してください。
関連項目
7.1.5. 配置グループがダウンしています
ceph health detail
コマンドは、一部の配置グループが down
していると報告します。
HEALTH_ERR 7 pgs degraded; 12 pgs down; 12 pgs peering; 1 pgs recovering; 6 pgs stuck unclean; 114/3300 degraded (3.455%); 1/3 in osds are down ... pg 0.5 is down+peering pg 1.4 is down+peering ... osd.1 is down since epoch 69, last address 192.168.106.220:6801/8651
エラー内容:
場合によっては、ピアリングプロセスはブロックでき、これにより配置グループがアクティブで使用可能になることを防ぐことができます。通常、OSD の障害によりピアリングの失敗が生じます。
この問題を解決するには、以下を行います。
ピア処理のブロックを決定します。
ceph pg <id> query
<id>
を、ダウンした配置グループの ID に置き換えます。以下に例を示します
。
# ceph pg 0.5 query { "state": "down+peering", ... "recovery_state": [ { "name": "Started\/Primary\/Peering\/GetInfo", "enter_time": "2012-03-06 14:40:16.169679", "requested_info_from": []}, { "name": "Started\/Primary\/Peering", "enter_time": "2012-03-06 14:40:16.169659", "probing_osds": [ 0, 1], "blocked": "peering is blocked due to down osds", "down_osds_we_would_probe": [ 1], "peering_blocked_by": [ { "osd": 1, "current_lost_at": 0, "comment": "starting or marking this osd lost may let us proceed"}]}, { "name": "Started", "enter_time": "2012-03-06 14:40:16.169513"} ] }
recovery_state
セクションには、ピアリングプロセスがブロックされた理由が含まれます。
-
osds のエラーメッセージが出て、出力にピア処理がブロックされる場合は
、「1 つ以上の OSD がダウンしている」 を参照してください。 - 他のエラーメッセージが表示された場合は、サポートチケットを開きます。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。
関連項目
- Red Hat Ceph Storage 3 の『管理ガイド』の「ピアリング 」セクション
7.1.6. 不明なオブジェクト
ceph health
コマンドは、unfound
キーワードを含む以下のようなエラーメッセージを返します。
HEALTH_WARN 1 pgs degraded; 78/3778 unfound (2.065%)
エラー内容:
これらのオブジェクトまたは新しいコピーが分かっている場合には、Ceph のマークは unfound
とマークしますが、オブジェクトが見つからないと判断できません。そのため、Ceph はそのようなオブジェクトを回復できず、復旧プロセスに進みます。
状況例
配置グループは、osd.1
および osd.2
にデータを格納します。
-
osd.1
はdown
します。 -
osd.2
は一部の書き込み操作を処理します。 -
osd.1
がup
とないります。 -
osd.1
とosd.2
の間のピアリングプロセスは開始し、osd.1
にないオブジェクトはリカバリーのためにキューに置かれます。 -
Ceph が新規オブジェクトをコピーする前に、
osd.2
がdown
となります。
その結果、osd.1
はこれらのオブジェクトが存在することを認識しますが、オブジェクトのコピーを持つ OSD はありません。
このシナリオでは、Ceph は障害が発生したノードが再びアクセス可能になるのを待機しており、未使用の unfound
によりリカバリープロセスがブロックされます。
この問題を解決するには、以下を行います。
unfound
オブジェクトが含まれる配置グループを決定します。# ceph health detail HEALTH_WARN 1 pgs recovering; 1 pgs stuck unclean; recovery 5/937611 objects degraded (0.001%); 1/312537 unfound (0.000%) pg 3.8a5 is stuck unclean for 803946.712780, current state active+recovering, last acting [320,248,0] pg 3.8a5 is active+recovering, acting [320,248,0], 1 unfound recovery 5/937611 objects degraded (0.001%); **1/312537 unfound (0.000%)**
配置グループに関する詳細情報を一覧表示します。
# ceph pg <id> query
<id>
を未検出オブジェクトが含まれる配置グループの ID に置き換えてください。以下に例を示します
。# ceph pg 3.8a5 query { "state": "active+recovering", "epoch": 10741, "up": [ 320, 248, 0], "acting": [ 320, 248, 0], <snip> "recovery_state": [ { "name": "Started\/Primary\/Active", "enter_time": "2015-01-28 19:30:12.058136", "might_have_unfound": [ { "osd": "0", "status": "already probed"}, { "osd": "248", "status": "already probed"}, { "osd": "301", "status": "already probed"}, { "osd": "362", "status": "already probed"}, { "osd": "395", "status": "already probed"}, { "osd": "429", "status": "osd is down"}], "recovery_progress": { "backfill_targets": [], "waiting_on_backfill": [], "last_backfill_started": "0\/\/0\/\/-1", "backfill_info": { "begin": "0\/\/0\/\/-1", "end": "0\/\/0\/\/-1", "objects": []}, "peer_backfill_info": [], "backfills_in_flight": [], "recovering": [], "pg_backend": { "pull_from_peer": [], "pushing": []}}, "scrub": { "scrubber.epoch_start": "0", "scrubber.active": 0, "scrubber.block_writes": 0, "scrubber.finalizing": 0, "scrubber.waiting_on": 0, "scrubber.waiting_on_whom": []}}, { "name": "Started", "enter_time": "2015-01-28 19:30:11.044020"}],
might_have_unfound
セクションには、Ceph がunfound
オブジェクトの検索を試行する OSD が含まれます。-
already probed
ステータスは、Ceph が OSD 内でunfound
オブジェクトを検出できないことを示します。 -
osd is down
状態は、Ceph が OSD と通信できないことを示します。
-
-
down
とマークされている OSD のトラブルシューティング詳しくは、「1 つ以上の OSD がダウンしている」 を参照してください。 -
OSD が
down
となる問題を修正できない場合は、サポートチケットを作成してください。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。
7.2. 配置グループが stale
、inactive
、または unclean State での一覧表示
失敗した後、配置グループは degraded
や peering
などの状態になります。この状態は、障害リカバリープロセスの通常の進捗を示しています。
ただし、配置グループがこれらの状態のいずれかの想定よりも長くなっている場合は、大きな問題があることを示す可能性があります。配置グループが最適ではない状態のまま状態のままになると、Monitor がレポートします。
以下の表には、この状態と簡単な説明をまとめています。
状態 | 意味 | 最も一般的な原因 | 参照 |
---|---|---|---|
| PG は読み取り/書き込み要求に対応することができません。 |
| |
| PG には、必要な回数を複製しないオブジェクトが含まれます。PG が復旧することを阻止している。 |
| |
|
PG のステータスは、 |
|
Ceph 設定ファイルの mon_pg_stuck_threshold
パラメーターは、配置グループが非アクティブ、適切ではない、または古いもの
とみなされるまでの秒数を決定します
。
スタックした PG を一覧表示します。
# ceph pg dump_stuck inactive # ceph pg dump_stuck unclean # ceph pg dump_stuck stale
関連項目
- 『Administration Guide for Red Hat Ceph Storage 3』の「Monitoring Placement Group States 」セクション
7.3. 包含の一覧表示
rados
ユーティリティーを使用して、オブジェクトのさまざまなレプリカで不整合を一覧表示します。より詳細な出力を一覧表示するには、--format=json-pretty
オプションを使用します。
以下を一覧表示できます。
プールに含まれる配置グループの一覧表示
rados list-inconsistent-pg <pool> --format=json-pretty
たとえば、data
という名前のプール内の一貫性のない配置グループの一覧を表示します。
# rados list-inconsistent-pg data --format=json-pretty [0.6]
配置グループでの包含オブジェクトの一覧表示
rados list-inconsistent-obj <placement-group-id>
たとえば、ID 0.6
の配置グループに一貫性のないオブジェクトの一覧を表示します。
# rados list-inconsistent-obj 0.6 { "epoch": 14, "inconsistents": [ { "object": { "name": "image1", "nspace": "", "locator": "", "snap": "head", "version": 1 }, "errors": [ "data_digest_mismatch", "size_mismatch" ], "union_shard_errors": [ "data_digest_mismatch_oi", "size_mismatch_oi" ], "selected_object_info": "0:602f83fe:::foo:head(16'1 client.4110.0:1 dirty|data_digest|omap_digest s 968 uv 1 dd e978e67f od ffffffff alloc_hint [0 0 0])", "shards": [ { "osd": 0, "errors": [], "size": 968, "omap_digest": "0xffffffff", "data_digest": "0xe978e67f" }, { "osd": 1, "errors": [], "size": 968, "omap_digest": "0xffffffff", "data_digest": "0xe978e67f" }, { "osd": 2, "errors": [ "data_digest_mismatch_oi", "size_mismatch_oi" ], "size": 0, "omap_digest": "0xffffffff", "data_digest": "0xffffffff" } ] } ] }
不整合な原因を特定するには、以下のフィールドが重要になります。
-
name
: 一貫性のないレプリカを持つオブジェクトの名前。 -
nSpace
: プールを論理的に分離する名前空間。デフォルトは空です。 -
Static
: 配置のオブジェクト名の代わりに使用されるキー。 -
snap
: オブジェクトのスナップショット ID。オブジェクトの書き込み可能な唯一のバージョンはhead
と呼ばれます。オブジェクトがクローンの場合、このフィールドには連続 ID が含まれます。 -
version
: 一貫性のないレプリカを持つオブジェクトのバージョン ID。オブジェクトへの書き込み操作はそれぞれ、オブジェクトにインクリメントします。 errors
: シャードの不一致を判別することなくシャード間の不整合を示すエラーの一覧。エラーをさらに調べるには、shard
アレイを参照してください。-
data_digest_mismatch
: 1 つの OSD から読み取られるレプリカのダイジェストは他の OSD とは異なります。 -
size_mismatch
: クローンのサイズまたはhead
オブジェクトが期待したサイズと一致しない。 -
read_error
: このエラーは、ディスクエラーが発生したために不整合が発生したことを示しています。
-
union_shard_error
: シャードに固有のすべてのエラーの結合。これらのエラーは、障害のあるシャードに接続されます。oi
で終わるエラーは、障害のあるオブジェクトからの情報と、選択したオブジェクトとの情報を比較する必要があることを示しています。エラーをさらに調べるには、shard
アレイを参照してください。上記の例では、
osd.2
に保存されているオブジェクトレプリカは、osd.0
およびosd.1
に保存されているレプリカとは異なるダイジェストを持ちます。具体的には、レプリカのダイジェストは、osd.2
から読み取るシャードから計算した0xffffffff
ではなく、0xe978e67f
です。さらに、osd.2
から読み込むレプリカのサイズは 0 ですが、osd.0
およびosd.1
によって報告されるサイズは 968 です。
配置グループにおける包含スナップショットセットの一覧表示
rados list-inconsistent-snapset <placement-group-id>
たとえば、ID 0.23
の配置グループにおける一貫性のないスナップショット (snapsets
) の一覧を表示します。
# rados list-inconsistent-snapset 0.23 --format=json-pretty { "epoch": 64, "inconsistents": [ { "name": "obj5", "nspace": "", "locator": "", "snap": "0x00000001", "headless": true }, { "name": "obj5", "nspace": "", "locator": "", "snap": "0x00000002", "headless": true }, { "name": "obj5", "nspace": "", "locator": "", "snap": "head", "ss_attr_missing": true, "extra_clones": true, "extra clones": [ 2, 1 ] } ]
このコマンドは、以下のエラーを返します。
-
ss_attr_missing
: 1 つ以上の属性がありません。属性は、キーと値のペアの一覧としてスナップショットセットにエンコードされるスナップショットに関する情報です。 -
ss_attr_corrupted
: 1 つ以上の属性がデコードできません。 -
clone_missing
: クローンがありません。 -
snapset_mismatch
: スナップショットセット自体に一貫性がありません。 -
head_mismatch
: スナップショットセットは、head
が存在するか、または存在しない場合はスクラブ結果を報告します。 -
headless
: スナップショットセットのhead
がありません。 -
size_mismatch
: クローンのサイズまたはhead
オブジェクトが期待したサイズと一致しない。
関連項目
7.4. 配置グループの修復
ディープスクラビングのエラーにより、一部の配置グループには不整合が含まれる場合があります。Ceph は、配置グループの inconsistent
をとります。
HEALTH_ERR 1 pgs inconsistent; 2 scrub errors pg 0.6 is active+clean+inconsistent, acting [0,1,2] 2 scrub errors
特定の不整合のみを修復できます。Ceph ログに以下のエラーが含まれる場合に配置グループを修復しないでください。
<pg.id> shard <osd>: soid <object> digest <digest> != known digest <digest> <pg.id> shard <osd>: soid <object> omap_digest <digest> != known omap_digest <digest>
代わりにサポートチケットを作成してください。詳しくは、9章Red Hat サポートサービスへのお問い合わせ を参照してください。
inconsistent
配置グループを修復します。
ceph pg repair <id>
<id>
を、一貫性のない配置グループの
ID に置き換えます。
関連項目
7.5. PG 数の増加
配置グループ(PG)数は、Ceph クラスターおよびデータ分散のパフォーマンスに影響します。これは、nearfull osds
エラーメッセージの主な原因の 1 つです。
1 OSD あたり 100 から 300 PG の推奨比率は、以下のようになります。この比率は、OSD をクラスターに追加する際に減少する可能性があります。
pg_num
パラメーターおよび pgp_num
パラメーターにより、PG 数が決まります。これらのパラメーターは各プールごとに設定されるため、PG の数が別々に低く、各プールを調整する必要があります。
PG 数を増やすことができます。これは、Ceph クラスターで実行できる最も集約型プロセスです。このプロセスは、速度が遅い方法で行われない場合に、パフォーマンスに深刻な影響を与える可能性があります。pgp_num
を増やすと、プロセスを停止したり元に戻したりすることはできず、完了する必要があります。
ビジネスの重要なプロセス時間割り当て外にある PG 数を増やし、パフォーマンスに影響を与える可能性のある可能性のあるクライアントをすべて警告することを検討してください。
クラスターが HEALTH_ERR
状態にある場合は、PG 数を変更しないでください。
手順: PG 数の追加
個別の OSD および OSD ホストでのデータ再分配および復旧の影響を減らします。
osd max backfills
、osd_recovery_max_active
、およびosd_recovery_op_priority
パラメーターの値を減らします。# ceph tell osd.* injectargs '--osd_max_backfills 1 --osd_recovery_max_active 1 --osd_recovery_op_priority 1'
シャローおよびディープスクラビングを無効にします。
# ceph osd set noscrub # ceph osd set nodeep-scrub
-
Ceph Placement Groups(PGs)per Pool Calculator
を使用して、pg_num パラメーターおよび
パラメーターの最適値を計算します。pgp_num
必要な値に達するまで、
pg_num
の値を少し増やします。- 開始の増分値を決定します。2 の累乗の値が非常に低い値を使用し、クラスターへの影響を決定する際にこの値を増やします。optimal の値は、プールサイズ、OSD 数、クライアント I/O 負荷により異なります。
pg_num
の値を増やします。ceph osd pool set <pool> pg_num <value>
プール名と新しい値を指定します。例を以下に示します。
# ceph osd pool set data pg_num 4
クラスターのステータスを監視します。
# ceph -s
PG の状態は、
creating
からactive+clean
に変わります。すべての PG がactive+clean
の状態になるまで待ちます。
必要な値に達するまで、
pgp_num
の値を少し増やします。- 開始の増分値を決定します。2 の累乗の値が非常に低い値を使用し、クラスターへの影響を決定する際にこの値を増やします。optimal の値は、プールサイズ、OSD 数、クライアント I/O 負荷により異なります。
pgp_num
の値を増やします。ceph osd pool set <pool> pgp_num <value>
プール名と新しい値を指定します。例を以下に示します。
# ceph osd pool set data pgp_num 4
クラスターのステータスを監視します。
# ceph -s
PG の状態は、
peering
、wait_backfill
、backfilling
、recover
などによって変わります。すべての PG がactive+clean
の状態になるまで待ちます。
- PG 数が十分にないすべてのプールに対して直前の手順を繰り返します。
osd max backfills
、osd_recovery_max_active
、およびosd_recovery_op_priority
をデフォルト値に設定します。# ceph tell osd.* injectargs '--osd_max_backfills 1 --osd_recovery_max_active 3 --osd_recovery_op_priority 3'
シャローおよびディープスクラビングを有効にします。
# ceph osd unset noscrub # ceph osd unset nodeep-scrub
関連項目
- 「Nearfull OSD」
- 『Administration Guide for Red Hat Ceph Storage 3』の「Monitoring Placement Group States 」セクション
第8章 オブジェクトのトラブルシューティング
ストレージ管理者は、ceph-objectstore-tool
ユーティリティーを使用して高レベルまたは低レベルのオブジェクト操作を実行することができます。ceph-objectstore-tool
ユーティリティーは、特定の OSD または配置グループ内のオブジェクトに関する問題のトラブルシューティングに役立ちます。
オブジェクトを操作すると、修復不能なデータ損失が発生する可能性があります。ceph-objectstore-tool
ユーティリティーを使用する前に、Red Hat サポートにお問い合わせください。
8.1. 前提条件
- ネットワーク関連の問題がないことを確認します。
8.2. オブジェクトレベルの操作のトラブルシューティング
ストレージ管理者は、ceph-objectstore-tool
ユーティリティーを使用して高レベルのオブジェクト操作を実行することができます。ceph-objectstore-tool
ユーティリティーは、以下の高レベルのオブジェクト操作をサポートします。
- オブジェクトの一覧表示
- 失われたオブジェクトを一覧表示
- 失われたオブジェクトの修正
オブジェクトを操作すると、修復不能なデータ損失が発生する可能性があります。ceph-objectstore-tool
ユーティリティーを使用する前に、Red Hat サポートにお問い合わせください。
8.2.1. 前提条件
-
Ceph OSD ノードへの
root
アクセスがある。
8.2.2. オブジェクトの一覧表示
OSD には、配置グループを多数に制限し、配置グループ(PG)内の多くのオブジェクトにゼロを含めることができます。ceph-objectstore-tool
ユーティリティーでは、OSD に保存されているオブジェクトを一覧表示することができます。
前提条件
-
Ceph OSD ノードへの
root
アクセスがある。 -
ceph-osd
デーモンの停止。
手順
適切な OSD がダウンしていることを確認します。
構文
systemctl status ceph-osd@$OSD_NUMBER
例
[root@osd ~]# systemctl status ceph-osd@1
配置グループに関係なく、OSD 内のすべてのオブジェクトを特定します。
構文
ceph-objectstore-tool --data-path $PATH_TO_OSD --op list
例
[root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --op list
配置グループ内のすべてのオブジェクトを特定します。
構文
ceph-objectstore-tool --data-path $PATH_TO_OSD --pgid $PG_ID --op list
例
[root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --pgid 0.1c --op list
オブジェクトが属する PG を特定します。
構文
ceph-objectstore-tool --data-path $PATH_TO_OSD --op list $OBJECT_ID
例
[root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --op list default.region
関連情報
8.2.3. 失われたオブジェクトの修正
ceph-objectstore-tool
ユーティリティーを使用して、Ceph OSD に保存されている 失われたオブジェクトおよび存在しないオブジェクト を一覧表示し、修正することができます。この手順は、レガシーオブジェクトにのみ適用されます。
前提条件
-
Ceph OSD ノードへの
root
アクセスがある。 -
ceph-osd
デーモンの停止。
手順
適切な OSD がダウンしていることを確認します。
構文
systemctl status ceph-osd@$OSD_NUMBER
例
[root@osd ~]# systemctl status ceph-osd@1
失われたレガシーオブジェクトをすべて一覧表示するには、次のコマンドを実行します。
構文
ceph-objectstore-tool --data-path $PATH_TO_OSD --op fix-lost --dry-run
例
[root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --op fix-lost --dry-run
ceph-objectstore-tool
ユーティリティーを使用して、失われたおよび未使用 のオブジェクトを修正します。適切な状況を選択します。失われたオブジェクトをすべて修正するには、以下を実行します。
構文
ceph-objectstore-tool --data-path $PATH_TO_OSD --op fix-lost
例
[root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --op fix-lost
配置グループ内で失われたオブジェクトをすべて修正するには、以下を実行します。
構文
ceph-objectstore-tool --data-path $PATH_TO_OSD --pgid $PG_ID --op fix-lost
例
[root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --pgid 0.1c --op fix-lost
失われたオブジェクトが識別子で修正するには、以下を実行します。
構文
ceph-objectstore-tool --data-path $PATH_TO_OSD --op fix-lost $OBJECT_ID
例
[root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --op fix-lost default.region
関連情報
8.3. 低レベルのオブジェクト操作のトラブルシューティング
ストレージ管理者は、ceph-objectstore-tool
ユーティリティーを使用して低レベルのオブジェクト操作を実行することができます。ceph-objectstore-tool
ユーティリティーは、以下の低レベルのオブジェクト操作をサポートします。
- オブジェクトの内容を操作します。
- オブジェクトの削除
- オブジェクトマップ(OMAP)を一覧表示します。
- OMAP ヘッダーを操作します。
- OMAP キーを操作します。
- オブジェクトの属性を一覧表示
- オブジェクトの属性キーを操作します。
オブジェクトを操作すると、修復不能なデータ損失が発生する可能性があります。ceph-objectstore-tool
ユーティリティーを使用する前に、Red Hat サポートにお問い合わせください。
8.3.1. 前提条件
-
Ceph OSD ノードへの
root
アクセスがある。
8.3.2. オブジェクトのコンテンツの操作
ceph-objectstore-tool
ユーティリティーを使用すると、オブジェクトのバイトを取得または設定できます。
オブジェクトにバイトを設定すると、回復できないデータ損失が発生する可能性があります。データの損失を防ぐには、オブジェクトのバックアップコピーを作成します。
前提条件
-
Ceph OSD ノードへの
root
アクセスがある。 -
ceph-osd
デーモンの停止。
手順
適切な OSD がダウンしていることを確認します。
構文
systemctl status ceph-osd@$OSD_NUMBER
例
[root@osd ~]# systemctl status ceph-osd@1
- OSD または配置グループ(PG)のオブジェクトを一覧表示してオブジェクトを検索します。
オブジェクトにバイトを設定する前に、バックアップとオブジェクトの作業コピーを作成します。
構文
ceph-objectstore-tool --data-path $PATH_TO_OSD --pgid $PG_ID \ $OBJECT \ get-bytes > $OBJECT_FILE_NAME ceph-objectstore-tool --data-path $PATH_TO_OSD --pgid $PG_ID \ $OBJECT \ get-bytes > $OBJECT_FILE_NAME
例
[root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --pgid 0.1c \ '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}' \ get-bytes > zone_info.default.backup [root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --pgid 0.1c \ '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}' \ get-bytes > zone_info.default.working-copy
- 作業コピーオブジェクトファイルを編集し、それに応じてオブジェクトの内容を変更します。
オブジェクトのバイトを設定します。
構文
ceph-objectstore-tool --data-path $PATH_TO_OSD --pgid $PG_ID \ $OBJECT \ set-bytes < $OBJECT_FILE_NAME
例
[root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --pgid 0.1c \ '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}' \ set-bytes < zone_info.default.working-copy
関連情報
8.3.3. オブジェクトの削除
ceph-objectstore-tool
ユーティリティーを使用してオブジェクトを削除します。オブジェクトを削除すると、そのコンテンツと参照は配置グループ(PG)から削除されます。
オブジェクトが削除されると、再作成できません。
前提条件
-
Ceph OSD ノードへの
root
アクセスがある。 -
ceph-osd
デーモンの停止。
手順
オブジェクトの削除
構文
ceph-objectstore-tool --data-path $PATH_TO_OSD --pgid $PG_ID \ $OBJECT \ remove
例
[root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --pgid 0.1c \ '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}' \ remove
関連情報
8.3.4. オブジェクトマップの一覧表示
ceph-objectstore-tool
ユーティリティーを使用して、オブジェクトマップ (OMAP) の内容を一覧表示します。この出力では、キーの一覧が表示されます。
前提条件
-
Ceph OSD ノードへの
root
アクセスがある。 -
ceph-osd
デーモンの停止。
手順
適切な OSD がダウンしていることを確認します。
構文
systemctl status ceph-osd@$OSD_NUMBER
例
[root@osd ~]# systemctl status ceph-osd@1
オブジェクトマップを一覧表示します。
構文
ceph-objectstore-tool --data-path $PATH_TO_OSD --pgid $PG_ID \ $OBJECT \ list-omap
例
[root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 --pgid 0.1c \ '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}' \ list-omap
関連情報
8.3.5. オブジェクトマップヘッダーの操作
ceph-objectstore-tool
ユーティリティーは、オブジェクトのキーに関連付けられた値と共にオブジェクトマップ (OMAP) ヘッダーを出力します。
FileStore を OSD バックエンドオブジェクトストアとして使用する場合は、オブジェクトマップヘッダーを取得または設定する際に、--journal-path $PATH_TO_JOURNAL
引数を追加します。ここで、$PATH_TO_JOURNAL
変数は OSD ジャーナルへの絶対パスです(例: /var/lib/ceph/osd/ceph-0/journal
)。
前提条件
-
Ceph OSD ノードへの
root
アクセスがある。 -
ceph-osd
デーモンの停止。
手順
適切な OSD がダウンしていることを確認します。
構文
systemctl status ceph-osd@$OSD_NUMBER
例
[root@osd ~]# systemctl status ceph-osd@1
オブジェクトマップヘッダーを取得します。
構文
ceph-objectstore-tool --data-path $PATH_TO_OSD \ --pgid $PG_ID $OBJECT \ get-omaphdr > $OBJECT_MAP_FILE_NAME
例
[root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \ --pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}' \ get-omaphdr > zone_info.default.omaphdr.txt
オブジェクトマップヘッダーを設定します。
構文
ceph-objectstore-tool --data-path $PATH_TO_OSD \ --pgid $PG_ID $OBJECT \ get-omaphdr < $OBJECT_MAP_FILE_NAME
例
[root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \ --pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}' \ set-omaphdr < zone_info.default.omaphdr.txt
関連情報
8.3.6. オブジェクトマップキーの操作
ceph-objectstore-tool
ユーティリティーを使用して、オブジェクトマップ (OMAP) キーを変更します。データパス、配置グループ識別子(PG ID)、オブジェクト、および OMAP のキーを指定する必要があります。
FileStore を OSD バックエンドオブジェクトストアとして使用する場合は、オブジェクトマップキーの取得、設定、または削除時に --journal-path $PATH_TO_JOURNAL
引数を追加します。ここで、$PATH_TO_JOURNAL
変数は OSD ジャーナルへの絶対パスです(例: /var/lib/ceph/osd/ceph-0/journal
)。
前提条件
-
Ceph OSD ノードへの
root
アクセスがある。 -
ceph-osd
デーモンの停止。
手順
オブジェクトマップキーを取得します。
構文
ceph-objectstore-tool --data-path $PATH_TO_OSD \ --pgid $PG_ID $OBJECT \ get-omap $KEY > $OBJECT_MAP_FILE_NAME
例
[root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \ --pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}' \ get-omap "" > zone_info.default.omap.txt
オブジェクトマップキーを設定します。
構文
ceph-objectstore-tool --data-path $PATH_TO_OSD \ --pgid $PG_ID $OBJECT \ set-omap $KEY < $OBJECT_MAP_FILE_NAME
例
[root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \ --pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}' \ set-omap "" < zone_info.default.omap.txt
オブジェクトマップキーを削除します。
構文
ceph-objectstore-tool --data-path $PATH_TO_OSD \ --pgid $PG_ID $OBJECT \ rm-omap $KEY
例
[root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \ --pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}' \ rm-omap ""
関連情報
8.3.7. オブジェクトの属性の一覧表示
ceph-objectstore-tool
ユーティリティーを使用して、オブジェクトの属性を一覧表示します。この出力には、オブジェクトのキーおよび値が表示されます。
FileStore を OSD バックエンドオブジェクトストアとして使用する場合は、オブジェクトの属性を一覧表示する際に --journal-path $PATH_TO_JOURNAL
引数を追加します。ここで、$PATH_TO_JOURNAL
変数は OSD ジャーナルへの絶対パスです(例: /var/lib/ceph/osd/ceph-0/journal
)。
前提条件
-
Ceph OSD ノードへの
root
アクセスがある。 -
ceph-osd
デーモンの停止。
手順
適切な OSD がダウンしていることを確認します。
構文
systemctl status ceph-osd@$OSD_NUMBER
例
[root@osd ~]# systemctl status ceph-osd@1
オブジェクトの属性を一覧表示します。
構文
ceph-objectstore-tool --data-path $PATH_TO_OSD \ --pgid $PG_ID $OBJECT \ list-attrs
例
[root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \ --pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}' \ list-attrs
関連情報
8.3.8. オブジェクト属性キーの操作
ceph-objectstore-tool
ユーティリティーを使用してオブジェクトの属性を変更します。オブジェクトの属性を操作するには、データとジャーナルパス、配置グループ識別子(PG ID)、オブジェクト、およびオブジェクトの属性のキーが必要です。
FileStore を OSD バックエンドオブジェクトストアとして使用する場合は、オブジェクトの属性の取得、設定、または削除時に --journal-path $PATH_TO_JOURNAL
引数を追加します。ここで、$PATH_TO_JOURNAL
変数は OSD ジャーナルへの絶対パスです(例: /var/lib/ceph/osd/ceph-0/journal
)。
前提条件
-
Ceph OSD ノードへの
root
アクセスがある。 -
ceph-osd
デーモンの停止。
手順
適切な OSD がダウンしていることを確認します。
構文
systemctl status ceph-osd@$OSD_NUMBER
例
[root@osd ~]# systemctl status ceph-osd@1
オブジェクトの属性を取得します。
構文
ceph-objectstore-tool --data-path $PATH_TO_OSD \ --pgid $PG_ID $OBJECT \ get-attrs $KEY > $OBJECT_ATTRS_FILE_NAME
例
[root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \ --pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}' \ get-attrs "oid" > zone_info.default.attr.txt
オブジェクトの属性を設定します。
構文
ceph-objectstore-tool --data-path $PATH_TO_OSD \ --pgid $PG_ID $OBJECT \ set-attrs $KEY < $OBJECT_ATTRS_FILE_NAME
例
[root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \ --pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}' \ set-attrs "oid" < zone_info.default.attr.txt
オブジェクトの属性を削除します。
構文
ceph-objectstore-tool --data-path $PATH_TO_OSD \ --pgid $PG_ID $OBJECT \ rm-attrs $KEY
例
[root@osd ~]# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-0 \ --pgid 0.1c '{"oid":"zone_info.default","key":"","snapid":-2,"hash":235010478,"max":0,"pool":11,"namespace":""}' \ rm-attrs "oid"
関連情報
8.4. 関連情報
- Red Hat Ceph Storage のサポートについては、Red Hat カスタマーポータル を参照してください。
第9章 Red Hat サポートサービスへのお問い合わせ
本ガイドの情報で問題の解決に役立ちなかった場合、本章では Red Hat サポートサービスへの連絡方法について説明します。
9.1. Red Hat サポートエンジニアへの情報の提供
Red Hat Ceph Storage に関する問題を修正できない場合は、Red Hat サポートサービスに連絡し、サポートエンジニアが問題解決時間を短縮するのに役立つ十分な量を提供します。
手順: Red Hat サポートエンジニアに情報の提供
- Red Hat カスタマーポータル でサポートチケットを作成します。
-
理想的には、
sosreport
をチケットに割り当てます。詳細は、「Red Hat Enterprise Linux 4.6 以降での sosreport の役割と取得方法」を参照してください。 - Ceph デーモンがセグメンテーション違反で失敗した場合には、人間が判読できるコアダンプファイルを生成することを検討してください。詳しくは、「読み取り可能なコアダンプファイルの生成」 を参照してください。
9.2. 読み取り可能なコアダンプファイルの生成
Ceph デーモンがセグメンテーション違反で突然終了すると、その障害に関する情報を収集し、Red Hat サポートエンジニアに提供します。
このような情報は初期調査を迅速化します。また、サポートエンジニアは、コアダンプファイルの情報を {storage-product} クラスターの既知の問題と比較できます。
9.2.1. 前提条件
ceph-debuginfo
パッケージがインストールされていない場合はインストールします。ceph-debuginfo
パッケージを含むリポジトリーを有効にします。subscription-manager repos --enable=rhel-7-server-rhceph-3-DAEMON-debug-rpms
ノードのタイプに応じて、DAEMON
をosd
またはmon
に置き換えます。ceph-debuginfo
パッケージをインストールします。[root@mon ~]# yum install ceph-debuginfo
gdb
パッケージがインストールされていることを確認します。インストールされていない場合は、インストールします。[root@mon ~]# yum install gdb
デプロイメントのタイプに基づいて、手順を続けます。
9.2.2. ベアメタルデプロイメント上の読み取り可能なコアダンプファイルの生成
ベアメタルで Red Hat Ceph Storage を使用する場合、以下の手順に従ってコアダンプファイルを生成します。
手順
Ceph のコアダンプファイルの生成を有効にします。
/etc/systemd/system.conf
ファイルに以下のパラメーターを追加して、コアダンプファイルに適切なulimits
を設定します。DefaultLimitCORE=infinity
デフォルトでは、
/lib/systemd/system/CLUSTER_NAME-DAEMON@.service
にある Ceph デーモンサービスファイルのPrivateTmp=true
パラメーターをコメントアウトします。[root@mon ~]# PrivateTmp=true
suid_dumpable
フラグを2
に設定して、Ceph デーモンがダンプコアファイルを生成できるようにします。[root@mon ~]# sysctl fs.suid_dumpable=2
コアダンプファイルの場所を調整します。
[root@mon ~]# sysctl kernel.core_pattern=/tmp/core
systemd
サービスを再読み込みし、変更を反映します。[root@mon ~]# systemctl daemon-reload
変更を有効にするために、Ceph デーモンを再起動します。
[root@mon ~]# systemctl restart ceph-DAEMON@ID
デーモンタイプ (
osd
またはmon
) とその ID (OSD の場合は数値、または Monitors の短縮ホスト名) を指定します。以下に例を示します。[root@mon ~]# systemctl restart ceph-osd@1
- 障害を再現します。たとえば、デーモンを再び起動してみてください。
GNU デバッガー(GDB)を使用して、アプリケーションのコアダンプファイルから読み取り可能なバックトレースを生成します。
gdb /usr/bin/ceph-DAEMON /tmp/core.PID
以下のように、デーモンのタイプと失敗したプロセスの PID を指定します。
$ gdb /usr/bin/ceph-osd /tmp/core.123456
GDB コマンドプロンプトで
set pag off
子マンとおよびset log on
コマンドを入力し、ページングを無効にし、ファイルへのロギングを有効にします。(gdb) set pag off (gdb) set log on
backtrace
を入力して、thr a a bt full
コマンドをプロセスのすべてのスレッドに適用します。(gdb) thr a a bt full
バックトレースが生成されたら、
set log off
を入力して電源をオフにします。(gdb) set log off
-
Red Hat カスタマーポータルにアクセスするシステムに
gdb.txt
ログファイルを転送して、サポートチケットにアタッチします。
9.2.3. コンテナー化されたデプロイメントで読み取り可能なコアダンプファイルの生成
以下の手順に従って、コンテナーで {storage-product} を使用する場合は、コアダンプファイルを生成します。この手順では、コアダンプファイルを取得する 2 つのシナリオが関係します。
- SIGILL、SIGTRAP、SIGSEGV エラーにより、Ceph プロセスが突然終了すると、SIGSEGV エラーが発生します。
または
- たとえば、Ceph プロセスなどの問題のデバッグを行う場合や、CPU サイクルが多い場合や応答しないなどを手動で行います。
前提条件
- Ceph コンテナーを実行するコンテナーノードへのルートレベルのアクセス。
- 適切なデバッグパッケージのインストール
-
GNU Project Debugger (
gdb
) パッケージのインストール。
手順
SIGILL、SIGTRAP、SIG ABRT、または SIGSEGV エラーにより、Ceph プロセスが突然終了する場合は、以下を実行します。
障害の発生した Ceph プロセスのあるコンテナーが実行しているノードの
systemd-coredump
サービスにコアパターンを設定します。以下に例を示します。[root@mon]# echo "| /usr/lib/systemd/systemd-coredump %P %u %g %s %t %e" > /proc/sys/kernel/core_pattern
Ceph プロセスが原因でコンテナーに関する次の障害の有無を確認し、
/var/lib/systemd/coredump/
ディレクトリーでコアダンプファイルを検索します。以下に例を示します。[root@mon]# ls -ltr /var/lib/systemd/coredump total 8232 -rw-r-----. 1 root root 8427548 Jan 22 19:24 core.ceph-osd.167.5ede29340b6c4fe4845147f847514c12.15622.1584573794000000.xz
Ceph Monitors および Ceph Managers のコアダンプファイルを手動でキャプチャーするには、以下を実行します。
コンテナーから Ceph デーモンの
ceph-mon
パッケージの詳細を取得します。[root@mon]# docker exec -it NAME /bin/bash [root@mon]# rpm -qa | grep ceph
NAME を、Ceph コンテナーの名前に置き換えます。
バックアップコピーを作成し、
ceph-mon@.service
ファイルを編集するために開きます。[root@mon]# cp /etc/systemd/system/ceph-mon@.service /etc/systemd/system/ceph-mon@.service.orig
ceph-mon@.service
ファイルで、これらの 3 つのオプションを[Service]
セクションに追加します。各オプションは 1 行ずつ追加します。--pid=host \ --ipc=host \ --cap-add=SYS_PTRACE \
例
[Unit] Description=Ceph Monitor After=docker.service [Service] EnvironmentFile=-/etc/environment ExecStartPre=-/usr/bin/docker rm ceph-mon-%i ExecStartPre=/bin/sh -c '"$(command -v mkdir)" -p /etc/ceph /var/lib/ceph/mon' ExecStart=/usr/bin/docker run --rm --name ceph-mon-%i \ --memory=924m \ --cpu-quota=100000 \ -v /var/lib/ceph:/var/lib/ceph:z \ -v /etc/ceph:/etc/ceph:z \ -v /var/run/ceph:/var/run/ceph:z \ -v /etc/localtime:/etc/localtime:ro \ --net=host \ --privileged=true \ --ipc=host \ 1 --pid=host \ 2 --cap-add=SYS_PTRACE \ 3 -e IP_VERSION=4 \ -e MON_IP=10.74.131.17 \ -e CLUSTER=ceph \ -e FSID=9448efca-b1a1-45a3-bf7b-b55cba696a6e \ -e CEPH_PUBLIC_NETWORK=10.74.131.0/24 \ -e CEPH_DAEMON=MON \ \ registry.access.redhat.com/rhceph/rhceph-3-rhel7:latest ExecStop=-/usr/bin/docker stop ceph-mon-%i ExecStopPost=-/bin/rm -f /var/run/ceph/ceph-mon.pd-cephcontainer-mon01.asok Restart=always RestartSec=10s TimeoutStartSec=120 TimeoutStopSec=15 [Install] WantedBy=multi-user.target
Ceph Monitor デーモンを再起動します。
構文
systemctl restart ceph-mon@MONITOR_ID
MONITOR_ID を Ceph Monitor の ID 番号に置き換えます。
例
[root@mon]# systemctl restart ceph-mon@1
Ceph Monitor コンテナーに
gdb
パッケージをインストールします。[root@mon]# docker exec -it ceph-mon-MONITOR_ID /bin/bash sh $ yum install gdb
MONITOR_ID を Ceph Monitor の ID 番号に置き換えます。
プロセス ID を検索します。
構文
ps -aef | grep PROCESS | grep -v run
PROCESS は、失敗したプロセス名 (例:
ceph-mon
) に置き換えます。例
[root@mon]# ps -aef | grep ceph-mon | grep -v run ceph 15390 15266 0 18:54 ? 00:00:29 /usr/bin/ceph-mon --cluster ceph --setroot ceph --setgroup ceph -d -i 5 ceph 18110 17985 1 19:40 ? 00:00:08 /usr/bin/ceph-mon --cluster ceph --setroot ceph --setgroup ceph -d -i 2
コアダンプファイルを生成します。
構文
gcore ID
ID を、前の手順で取得した失敗したプロセスの ID に置き換えます (例:
18110
)。例
[root@mon]# gcore 18110 warning: target file /proc/18110/cmdline contained unexpected null characters Saved corefile core.18110
コアダンプファイルが正しく生成されていることを確認します。
例
[root@mon]# ls -ltr total 709772 -rw-r--r--. 1 root root 726799544 Mar 18 19:46 core.18110
Ceph Monitor コンテナー外でコアダンプファイルをコピーします。
[root@mon]# docker cp ceph-mon-MONITOR_ID:/tmp/mon.core.MONITOR_PID /tmp
MONITOR_ID を Ceph Monitor の ID 番号に置き換え、MONITOR_PID をプロセス ID 番号に置き換えます。
ceph-mon@.service
ファイルのバックアップコピーを復元します。[root@mon]# cp /etc/systemd/system/ceph-mon@.service.orig /etc/systemd/system/ceph-mon@.service
Ceph Monitor デーモンを再起動します。
構文
systemctl restart ceph-mon@MONITOR_ID
MONITOR_ID を Ceph Monitor の ID 番号に置き換えます。
例
[root@mon]# systemctl restart ceph-mon@1
- Red Hat サポートが分析するためのコアダンプファイルをアップロードする場合は、ステップ 4 を参照してください。
Ceph OSD のコアダンプファイルを手動でキャプチャーするには、以下を実行します。
コンテナーから Ceph デーモンの
ceph-osd
パッケージの詳細を取得します。[root@osd]# docker exec -it NAME /bin/bash [root@osd]# rpm -qa | grep ceph
NAME を、Ceph コンテナーの名前に置き換えます。
Ceph コンテナーが実行しているノードに、同じバージョンの
ceph-osd
パッケージ用の Ceph パッケージをインストールします。[root@osd]# yum install ceph-osd
必要に応じて、適切なリポジトリーを最初に有効にします。詳細は、『インストールガイド』の「Red Hat Ceph Storage リポジトリーの有効化 」セクションを参照してください。
障害が発生したプロセスの ID を検索します。
ps -aef | grep PROCESS | grep -v run
PROCESS は、失敗したプロセス名 (例:
ceph-osd
) に置き換えます。[root@osd]# ps -aef | grep ceph-osd | grep -v run ceph 15390 15266 0 18:54 ? 00:00:29 /usr/bin/ceph-osd --cluster ceph --setroot ceph --setgroup ceph -d -i 5 ceph 18110 17985 1 19:40 ? 00:00:08 /usr/bin/ceph-osd --cluster ceph --setroot ceph --setgroup ceph -d -i 2
コアダンプファイルを生成します。
gcore ID
ID を、前の手順で取得した失敗したプロセスの ID に置き換えます (例:
18110
)。[root@osd]# gcore 18110 warning: target file /proc/18110/cmdline contained unexpected null characters Saved corefile core.18110
コアダンプファイルが正しく生成されていることを確認します。
[root@osd]# ls -ltr total 709772 -rw-r--r--. 1 root root 726799544 Mar 18 19:46 core.18110
- Red Hat サポートが分析するためのコアダンプファイルをアップロードします。次の手順を参照してください。
- Red Hat サポートケースへの分析用のコアダンプファイルをアップロードします。詳細は、「Red Hat サポートエンジニアへの情報の提供」を参照してください。
9.2.4. 関連情報
- Red Hat Customer Portal の 「gdb を使用して、アプリケーションコアから読み取り可能なバックトレースを生成する方法」
- Red Hat カスタマーポータルの「アプリケーションがクラッシュまたはセグメンテーション違反が発生した時にコアファイルのダンプを有効にする」
付録A サブシステムのデフォルトロギングレベルの値
サブシステム | ログレベル | メモリーレベル |
---|---|---|
| 1 | 5 |
| 1 | 5 |
| 0 | 0 |
| 0 | 5 |
| 0 | 5 |
| 1 | 5 |
| 0 | 5 |
| 0 | 5 |
| 1 | 5 |
| 1 | 5 |
| 1 | 5 |
| 1 | 5 |
| 0 | 5 |
| 1 | 5 |
| 0 | 5 |
| 1 | 5 |
| 1 | 5 |
| 1 | 5 |
| 1 | 5 |
| 1 | 5 |
| 1 | 5 |
| 0 | 5 |
| 1 | 5 |
| 0 | 5 |
| 0 | 5 |
| 0 | 5 |
| 0 | 0 |
| 0 | 5 |
| 0 | 5 |
| 0 | 5 |
| 1 | 5 |
| 0 | 5 |
| 0 | 5 |
| 1 | 5 |
| 1 | 5 |
| 0 | 5 |
| 0 | 5 |